Community
Participate
Working Groups
Build: I20050921-0010 I understand the need for categories in the import/export wizards to help organize the set of available options. However, the current categories seem to be split along plugin boundaries, which isn't particularly useful to the user. For example, "Preferences" and "File System" are currently in the same category, although they are wildly different things. On the other hand, "JAR file" and "Archive file" are nearly identical, but in different categories. I'm wondering if it would make more sense to create categories according to the data being exported: + Files + Archive file + Jar file + File system + Settings + Preferences + Breakpoints + Team project sets I don't know what category "Ant Buildfiles" would go in. Since it doesn't even export anything it doesn't look like it belongs there at all (I entered bug 110244 for that).
I think part of the categorization problem is that the current set of wizard names do not represent something consistent. In the export wizard, it says "Select an export destination". With the options below including "Preferences" and "Breakpoints", clearly it is not necessarily a "destination" that is being selected here. Perhaps instead of a "category" and "name", export wizards should provide strings for "dataType" and "destination", where "dataType" indicates what you are exporting, and "destination" indicates where are you putting it. That would allow you to build a common UI with more consistency.
We initially considered functional category names, but decided that categories macthing the new wizards would be more comfortable (read: familiar) for the user. The current way seems to work for the plugin import and export wizards, but we could also use a functional category for Jar/Archive imports and exports. As for the message "Choose an export destination", i think if we just change "destination" to "wizard" we could solve that problem without having to add extra infrastructure (I assume this would be mandatory, based on your description) that the user needs to understand. We do not know the nature of some of the wizards in the larger scale products so having them provide a dataType and destination may be too restrictive. The reason I say this is because you can provide an import/export wizard that does just about anything. What would the dataType and destination be for import > Checkout projects from CVS?
It was just an idea... I realize it's hard to group these things because there's such a grab-bag of functionality in the import/export wizards (and who knows what kind of wizards other plugins are adding on top of the platform). The CVS case seems easy though, the data type is "Files" and the source is "CVS repository". In any case, I think an "Archive" category makes sense, because I'm sure products have import wizards for all kinds of archive files: jar, war, ear, zip, tar, etc. This reminds me that the current wizard called "Archive File" should probably be called "Zip/Tar file" because there are many kinds of archive files it does not support.
I wasn't implying the idea was a bad one, just letting you know why we went the way we did on the first cut. This should still be considered as something to change. And you are right about the many different flavors of Archive exports in the larger scale products. I wonder if a mix of functionally named categories as well as those that are split along plugin boundaries is feasible. I see the Plugin Development category being useful, but also an Archive category and a Settings category, as you mentioned would be nice.
"As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009"
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
