| Summary: | [patch] Extensions tree viewer should also be filtered by leaf item's attributes | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] PDE | Reporter: | Sascha Becher <becher-sascha> | ||||||||||||||
| Component: | UI | Assignee: | Curtis Windatt <curtis.windatt.public> | ||||||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||||||
| Severity: | enhancement | ||||||||||||||||
| Priority: | P3 | CC: | curtis.windatt.public, daniel_megert, john.arthorne, ob1.eclipse | ||||||||||||||
| Version: | 4.2 | Keywords: | contributed, noteworthy | ||||||||||||||
| Target Milestone: | 3.8 M6 | ||||||||||||||||
| Hardware: | PC | ||||||||||||||||
| OS: | Windows Vista | ||||||||||||||||
| Whiteboard: | |||||||||||||||||
| Bug Depends on: | 186404 | ||||||||||||||||
| Bug Blocks: | 360079, 371066, 372803 | ||||||||||||||||
| Attachments: |
|
||||||||||||||||
|
Description
Sascha Becher
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. 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] |