Bugzilla – Full Text Bug Listing
| Summary: | Remove/reduce plug-in loading dependency in Run context menu | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Jared Burns <jared_burns> | ||||||
| Component: | Debug | Assignee: | Chris Tilt <chris> | ||||||
| Status: | RESOLVED DUPLICATE | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | chris, darin.eclipse | ||||||
| Version: | 3.0 | ||||||||
| Target Milestone: | 3.0 M8 | ||||||||
| Hardware: | PC | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | |||||||||
| Bug Blocks: | 51506 | ||||||||
| Attachments: |
|
||||||||
|
Description
Jared Burns
After discussing it a bit, I suggest adding support for "contextNameFilter" and "contextVisibility" elements. Before the filterClass is loaded, the menu should add all shortcuts that pass these filters. Once the filterClass is loaded, it should use the xmlFilters first and then run the filterClass. This not only solves the "Run Ant..." problem, it also solves the problem of applicable shortcuts not appearing when they should. For example, "Run Java Application" would appear on all *.java files before JDT is loaded. This means it would show up on files that don't have main methods, but I think that's better than *not* having it show up on files that do. If the filtering isn't precise, I think it should be imprecise in favor of the user's ability to perform their desired action (launch their app). This sounds like a nice improvement, that I think we should try. My concern is that it could cause many options to appear in the menu. I.e. if there are tons of shortcuts for ".java" files in a product, will they all show up all the time in the case that those plug-ins are never loaded/used? Created attachment 7759 [details]
nameFilter addition, part one of two
Created attachment 7760 [details]
nameFilter addition, part two of two
adds a nameFilter attribute to the launch shortcut extension that allows
optimistic inclusion of launch shortcuts to the context menu. If the plugin
containing the filterClass is not loaded yet, nameFilter decides the
visibility. If the filterClass is loaded, nameFilter && filterClass tests
decide. This seems like a good middle ground for context menu population.
Applied patches and released to HEAD. The supplied patch adds support for a single nameFilter, but we should expand this a bit to support multiple names. For example, the Java stuff wants to specify "*.java,*.class". Expanding the name filter to support a list of patterns is better, but does not solve the whole problem. Consider multi-selections that require an XML, XSL, and Java file to be selected. So, the thing to consider is how to allow generic filtering that can serve as the first order approximation before loading the plugin that really knows wether the shortcut applies to the selection. The issue of multi-selection is what makes it interesting. I propose a fancier version of the existing nameFilter, which currently only supports a basic pattern of "*.ext". The new version would also support logical OR "||", AND "&&", ONE OR MORE "+", and ZERO OR MORE "*", as well as parenthetical grouping of basic terms (don't see a case or allowing arbitrary grouping and instance counts). nameFilter="*.java && *.xml && *.xsl" - one java, one xml and one xsl file nameFilter="*.java || *.class" - one of either a java or class file nameFilter="(*.java)+" - one or more java files nameFilter="(*.xml)* && *.java" - zero or more xml files and one java file Adding Darin as a CC to get his comments. This proposal will also be key in addressing bug #51506 Bug #54717 subsumes this request. *** This bug has been marked as a duplicate of 54717 *** |