Community
Participate
Working Groups
It would be great if the PDE would create a way of opening up a plugin.xml file based on the plug-in's identifier, and/or translated name. I'm sure they could go and create a new dialog, but that approach doesn't scale very well. Web tooling might want to create a similar way of opening project configuration files. I think the platform should create a unified open dialog that can be switched to "Type" mode, "Plug-in" mode, "Resource" mode, etc., via extensions that perform indexing and provide the matching mechanism (e.g. camel-case matching). Otherwise we'll run out of CTRL+SHIFT+ accelerators. Sorry if this is a dupe.
MvM?
you're suggesting something like the unified search dialog?
Absolutely. Although both dialogs could probably be enhanced with something like a MRU history that appears above the categorization tabs.
As part of bug #94382, I'm working on a common viewer-like component (perhaps a full-fledged viewer) that filters a list, manages the MRU list (much like the open type dialog), etc. As a viewer-like component, it can be used in dialogs, wizards, popup dialogs, etc. This bug is really an additional request, correct? The idea of a common open dialog, where the goal is not just to provide common behavior, but to give the user a single place to go to open anything by name. Interesting idea. Just wanted to make sure that this request is not confused with the effort to share the code in the open type dialog with open resource and other dialogs. This would be a different effort, not currently planned, but could be considered... cc'ing Dirk for thoughts. Would this be useful in any of your scenarios?
changing prio and status to conform to plat-ui bug guidelines
As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009
@Dani: do you think the "open" story would also be handled by a common "ltk" bundle or should it be separate? Maybe it would make more sense in the Search component?
(In reply to Mickael Istria from comment #7) > @Dani: do you think the "open" story would also be handled by a common "ltk" > bundle or should it be separate? Maybe it would make more sense in the > Search component? LTK.
