Community
Participate
Working Groups
Build Identifier: 20110615-0604 I often work with large lists of extensions: commands, handlers and menu contributions. The visual component for editing extensions requires me to search for tree items (and also the xml view). This is often costly in terms of time. When I click on a command, I would like to instantly filter for it's implementing handler entries, related menu contributions, activities, bindings and the command image. This could be achieved by enabling the filter text field to also filter for attribute values of the tree's items. The default behaviour only lets one filter for the label in the tree, which would still be available. I already implemented this feature and found it quite useful at work. The patch applied here provides: * Filtering for attribute values of tree items as well as labels with wildcards (default behaviour) * Multiple filter patterns allowed by delimiter item: / * Bugfix: matching item's children are being displayed * org.eclipse.ui.handlers: class name without package now displayed instead of only (handler) * Elements of type (test) are being displayed with their property attribute instead of only (test) * Filter Related: context menu function added for quick overview of related items. Attributes supported: label, id, class, commandId, value, pattern, locationURI, defaultHandler * Filter Related: keybinding applied from global command Find (default: Ctrl+F) * Filter Related: context menu item only shown when selected item has attributes to filter with * Filter Related: also supports multi selection in tree This approach to filtering for attributes also enables finding of related items from any direction. For instance searching from a menu contribution will also reveal the command, handlers and alike. This works also with other extension types because related items often share the same attribute values (id, value, label, class...). The Filter requires to accept multiple values by the delimeter item '/'. This works also fine with activities, as the pluginId there is separated by the id to listen to with '/'. All attribute values are chopped off after character '?' in order to find also find menus with the locationURI notation toolbar:org.eclipse.pde.ui.PluginsView?after=additions, because the value of after=... can be different. To extend PatternFilter from org.eclipse.ui.workbench I needed to fix Bug 186404. So the patch applied here also requires to apply the patch for 186404. Reproducible: Always Steps to Reproduce: 1. open any plugin.xml in the PDE editor 2. add 100 commands and implementing handlers to the tree 3. close and re-open the editor, go the extensions page 4. try to find a specific handler for a command
Created attachment 205156 [details] patches eclipse.pde.ui This patch may be made against my local git repositiory with wrong formatting options (tabs instead of spaces). I'm not sure about this and would fix it if necessary.
Created attachment 205157 [details] Patch for bug 186404
Here you will find a description, screenshot and a compiled version enhancements: http://www.stereotron.com/pde-enhancement (until the end of 2011)
Will review for M4, but I don't know if platform UI will be able to review the change to the pattern filter API.
Created attachment 209727 [details] Git-Patch against 3.8 M4 [master], please add icons from the next attachement Actions: - "Filter related" fills the filter text with the values of a list of attributes when found on the selected tree node. These attributes for relation are: label, id, class, commandId, value, pattern, locationURI, defaultHandler The action is presented by a toolbar icon, in the context menu of the tree and by pressing Ctrl+F (key binding of "Find"). Multi-Selection is supported but can be costly. The action is only enabled when at least one item of the selection is supported by the attributes for relation. - "Search Extension Element": starts a workspace-wide search with current filter set to the tree. Displays search results in Search View with a distinct icon. Opening a search result reveals the extensions page with the filter already being applied to the tree. One might find this useful i.e. for finding implementing handlers or menu contributions of remote command definitions and alike. The action is only enabled when filtering occurs. - "Search Related" (context menu only) combines Filter Related with Search Extension Elements by performing a workspace wide search for the attributes supported by Filter Related found on the currently selected tree node(s). - "Toggle Expand State" expands and collapses selected tree node(s) for convenient reading of large expressions or for hiding only parts of the tree. All actions have icons designed to reveal their purpose. Other Features: - Typing into the filter doesn't get blocked any more by extensive search operations. Running search operations are being canceled when the filter text changes. - Sensible tree expand behaviour: a filtered tree now contains also all children of the matching elements in collapsed state. - LabelProvider of the tree displays these extension elements with the following attributes: (test): property, (handler): class, (activityPatternBinding): activityId, (propertyTester): class The label provider has a list of attributes to visit each tree node with in order to obtain the label text. That list has been completed to display even more elements with their most distinctive attribute: label, name, class, id, commandId, property, activityId, attribute, value - Any value found for the attribute "class" is displayed without the package to minimize label length. - Attribute values with the notation "id1?after=id2" found for "Filter Related" are being split into id1/id2 in order to find the location of item with id2, thus learning where it appears in the UI or elsewhere.
Created attachment 209729 [details] Icons required for the patch Imported to org.eclipse.pde.ui: dlcl16, elcl16, obj16
This patch still requires additional changes to Platform UI in bug 186404, correct?
No, it did compile against 3.8M4 without any changes to the workbench project. Solution to Bug 186404 seems to be already part of 3.8M4.
You reopened bug 186404 suggesting it was not complete. If no additional changes are needed, please close it as fixed. I will review the patch for M6 then.
I'm lacking the rights to do so but left a comment that it can be set to FIXED.
Created attachment 211150 [details] Extensions page enhancements Features: - Tree filter accepts element attribute values to filter the tree with. - Filters for multiple attributes when using split character / - Matching leafs are highlighted with font style bold. - The label provider of the tree has a list of attributes to visit each tree node with in order to obtain the label text. That list has been completed to display even more elements with their most distinctive attribute: label, name, locationURI, class, id, commandId, property, activityId, attribute, value - Elements labeled with the value of "class" ar displayed without the package to minimize label length. - Attribute values with the notation "id1?after=id2" found for "Filter Related" are being split into id1/id2 in order to find the location of item with id2, thus learning where it appears in the UI or elsewhere. - Sensible tree expand behaviour: a filtered tree now contains also all children of the matching elements in collapsed state. - "Filter related" applied to an element of type test finds the property tester - Accelerated tree scrolling with Ctrl + Mousewheel (like text editor) - Ctrl+F in Extension Details form applies attribute to the tree filter, attributes containing '/' are quoted to be searched without splitting - Fixed: Bug 371066 - Manifest editor extensions tab tree scrolls upwards on save - Fixed: Bug 360079 - Ctrl+V and Ctrl+Z still doesn't work in filter text field of extensions page of plugin editor - SortAction retains expanded state of the tree on sorting - Adding elements and extensions during tree filtering is available Actions: - "Filter related" sets the filter text with the values of a list of attributes when found on the selected tree element. These attributes for relation are: id, class, commandId, pattern, locationURI, defaultHandler, variable, property, contentTypeId, path, plugin, perspective, targetID This action is presented by a toolbar icon, in the context menu of the tree and by pressing Ctrl+F (key binding of "Find"). Multi-Selection is supported but can be costly. The action is only enabled when at least one item of the selection has attributes for related filtering. At most 30 attributes are filtered. - "Search Extension Element": starts a workspace-wide plugin search with current filter set to the tree. Displays search results in Search View with a distinct icon. Opening a search result reveals the extensions page with the filter already being applied to the tree. One might find this useful i.e. for finding implementing handlers or menu contributions of remote command definitions and alike. The action is only enabled when filtering occurs. - "Search Related" (context menu only) combines Filter Related with Search Extension Elements by performing a workspace wide search for the attributes supported by Filter Related found on the currently selected tree node(s) without filtering the current tree. - "Toggle Expand State" expands and collapses selected tree node(s) for convenient reading of large expressions or for hiding only parts of the tree. - "Show all extensions" (context menu) reveals all extensions when filtering. This is to add elements that might be missing as a result of the search. "Hide unfiltered extensions" reverses the action. Some actions have icons designed to reveal their purpose, see attachment 209729: Icons required for the patch I can contribute documentation for Eclipse Help if necessary.
This is a great contribution! While testing the only issue I saw was that the extension element search button on the toolbar was not enabled when selecting an element, but the context menu still contained the action and was runnable. However, I want to get through the ip process before looking at fixing this. This contribution was larger than I originally had thought, so I will need to do a CQ for legal. Before I start that process, can you provide the necessary legal message as a comment on this bug? The details of the message, including an example are at: http://www.eclipse.org/tm/development/committer_howto.php#external_contrib
Legal Message: I, Sascha Becher, declare that I developed attached code from scratch, without referencing any 3rd party materials except material licensed under the EPL. I certify that I am the copyright owner and authorize this contribution and eventual consecutive changes made by me.
Created attachment 211250 [details] Additional changes (1) on top of 211150 The action was disabled because the tree wasn't filtered. I have fixed that. The context menu and toolbar action 'Search related' are working the same way now. Since it is possible to type into the the filter text or get attributes from the element details form, one might want to search for this as well. Right to the filter text there is a Search button that does this. Other changes include: - Default filtering behaviour (PatternFilter#wordMatches) changed. There is no need to filter the label because the label text is only another attribute. Instead wordMatches() tests for the element name or extension point. Thus it is possible to find all perspectives using 'perspective' or find all services using '*services'. The attribute search on the other hand doesn't allow the use of wildcards. - Several relations added for Filter/Search Related (see ExtensionsFilterUtils) - Minor bugfix to AcceleratedTreeScrolling - some name refactoring I'd like to improve the Search View results. Is it okay if I send another patch on top of this in a few days?
(In reply to comment #14) > I'd like to improve the Search View results. Is it okay if I send another patch > on top of this in a few days? I will be submitting the CQ for attachment 211150 [details]. The additional changes patch and any future fixes can be added after the CQ is complete as they will be much smaller in size. It would be better to have a separate bug report for them.
CQ: https://dev.eclipse.org/ipzilla/show_bug.cgi?id=6278
I'm sorry to be the messenger with the bad news: the CQ deadline for Juno has long passed (Feb. 3, 2012). Moving target to 4.3.
This can't be real! - This is just an enhancement to an existing component, not a new feature or even a new project. - It is useful mainly for 3.x model applications, so publishing it in 2013 makes it virtually useless. - It's been uploaded before Feb.3, yet refined until (see obsoletes) I have invested a lot of time into this. The code is written by me, no cryptography or anything special, just a modified tree filtering behaviour. And finally, your project plan needs to make this CG deadline VERY clear, at best around the target milestone dates, which I had in mind only.
(In reply to comment #18) > This can't be real! > - This is just an enhancement to an existing component, not a new feature > or even a new project. > - It is useful mainly for 3.x model applications, so publishing it in 2013 > makes it virtually useless. > - It's been uploaded before Feb.3, yet refined until (see obsoletes) > I have invested a lot of time into this. The code is written by me, no > cryptography or anything special, just a modified tree filtering behaviour. > And finally, your project plan needs to make this CG deadline VERY clear, > at best around the target milestone dates, which I had in mind only. Don't beat the messenger ;-). I can see your frustration but the deadline is well known and given. It has been posted on several blogs and mailing lists, e.g. http://www.mail-archive.com/cross-project-issues-dev@eclipse.org/msg00357.html. Having said that, it's not your fault. The committers should point contributors to that date early in the process. The deadline is needed because the legal team is small and only an early deadline guarantees to those who file the CQ on time, that their contributions get reviewed and legally cleared for the release. Many people use milestone and even integration builds, for those the feature will be available much earlier.
Curtis, since the patch was here before the CQ deadline and we didn't notice its size, I suggest you ask in the CQ whether the IP team could make an exception.
I apologize for missing the deadline and hope that this will not discourage you from contributing to Eclipse in the future. This is a great set of improvements that will get used by many people even if not included in the official Juno release. (In reply to comment #20) > Curtis, since the patch was here before the CQ deadline and we didn't notice > its size, I suggest you ask in the CQ whether the IP team could make an > exception. Done
Eclipse legal has approved the CQ. The fix from attachment 211150 [details] has been fixed in master. Sascha, in addition to the 'additional changes' patch attached, you said you had a few more tweaks. The changes should be contributed as a new bug. Let me know if you can create the new bug and patch or if you would like me to do so.
Thanks for your immediate response and review! Last Patch is on Bug 372803 - Extension Element Search shows wrong match count and needs to be applied after attachment 211250 [details]
