Community
Participate
Working Groups
Build ID: Eclipse SDK 3.6m5 As a user, I want to hide all backup and object files from my Eclipse resource tree, such that I can concentrate on what's relevant. I want to do this with a simple UI that I can understand intuitively. The resource filters are a great new concept, and the UI is extremely powerful. But I am afraid that as of Eclipse 3.6m5, the most common, simple tasks are too hard to do. I'm sorry for bringing this up late -- Only now, after this feature is sure to go into our commercial product, I have a much stronger interest in making the feature really usable beyond being a preview of technology. Here is a concrete suggestion: 1.) For grouping filters (AND,OR,NOT), have a separate dialog ("Add Group...") rather than managing this through the single "Add..." dialog. Rationale: - I expect that groups will be needed much less than "normal" filters - Groups are conceptionally different than "normal" filters 2.) For search patterns, use the same concept as used in many other places at Eclipse, like the Search dialog for instance: - Use glob patterns by default - Have a checkbox for "Regular Expression" beside. - For glob patterns, allow listing multiple patterns separated by , This is the same as "search" does for file names. Users will intuitively understand and appreciate this metaphor used elsewhere. Plus, I guess that the most common use for filters is hiding stuff like *.o, *.obj, *~, *.bak --> This most common use case should be most easy to use. My 3rd and 4th suggestions are less important: 3.) Instead of the "Include" and "Exclude" icons, which not really fit too well into the iconset used elsewhere at Eclipse, have a checkbox for "hide matching" beside the filter patterns to flip the meaning of the patterns from "include only" to "hide specified". 4.) Instead of the "Inheritable" option, call this option (X) Apply recursively to folder structure and put it below the filter patterns to enter. Again, sorry for bringing this up late, but I am very confident that these suggestions would greatly improve usability of the feature for casual or beginning users.
(In reply to comment #0) > Build ID: Eclipse SDK 3.6m5 > > > Here is a concrete suggestion: > > 1.) For grouping filters (AND,OR,NOT), have a separate dialog ("Add Group...") > rather than managing this through the single "Add..." dialog. > Rationale: > - I expect that groups will be needed much less than "normal" filters > - Groups are conceptionally different than "normal" filters > I think it's a good point. > 2.) For search patterns, use the same concept as used in many other places > at Eclipse, like the Search dialog for instance: > - Use glob patterns by default > - Have a checkbox for "Regular Expression" beside. > - For glob patterns, allow listing multiple patterns separated by , > This is the same as "search" does for file names. Users will intuitively > understand and appreciate this metaphor used elsewhere. Plus, I guess > that the most common use for filters is hiding stuff like > *.o, *.obj, *~, *.bak > --> This most common use case should be most easy to use. > Would having the 'String Matcher' type as default satisfy your requirement? The general idea, here, is that UI simply displays the filter type list. This is extensible from 3rd party plugins, so that in order for the UI to work properly with other types, it can't be too customized to a single type. Also, For example, a plugin might want to implement a CVS filter type, that removes files from the workspace based in their cvs status. > My 3rd and 4th suggestions are less important: > > 3.) Instead of the "Include" and "Exclude" icons, which not really fit too > well into the iconset used elsewhere at Eclipse, have a checkbox for > "hide matching" beside the filter patterns to flip the meaning of the > patterns from "include only" to "hide specified". I believe those icons have been reviewed by the UI gurus. But I believe that displaying icons to show the include/exclude type is consistent with the other Eclipse UI. If you look at the Java BUild Path property page, in the Type Access Rules UI, there's 3 mode (Forbidden/Discouraged/Accessible, and 3 icons for each. Although I think the filter UI icons look better. > 4.) Instead of the "Inheritable" option, call this option > (X) Apply recursively to folder structure > and put it below the filter patterns to enter. > Ok, sure. > Again, sorry for bringing this up late, but I am very confident that these > suggestions would greatly improve usability of the feature for casual or > beginning users. No problem, I appreciate your input.
(In reply to comment #1) > Would having the 'String Matcher' type as default satisfy your requirement? > > The general idea, here, is that UI simply displays the filter type list. Ha, I knew you'd argue like this :) I think that the "filter type" is too hard to understand for a casual user or beginner, it looks unfamiliar. I propose restricting the "Add..." dialog to String Matcher and Regex as outlined in comment 0. What about calling the 2nd button "Add Special..." instead of "Add Group..." and use your existing dialog with the dropdown there? > For example, a plugin might want to implement a CVS filter type, that removes > files from the workspace based in their cvs status. Can such contributed filter types take an argument like the current patterns? If not, then putting the "pattern-like" filters in one dialog and the "contributed special" filters in another one, we are perfectly fine.
I agree with you, I'll make the changes as soon as I have a chance.
Something else I think the Filter UI should support, is custom UI for custom filters. Right now, the user can only enter strings as arguments. But what if a filter takes a date? The user has to enter it manually as a string, and hope he has the syntax right. What the ui.ide should do, is have a schema for an extension point that allows third party plugins to contribute "Filter Argument editors" so that they can provide a custom editor that serialize and unserialize to the internal proper string format by showing a proper UI to the user. This would qualify as an API change, though.
Created attachment 161429 [details] First change: "Add group..."
Created attachment 163828 [details] Second change Includes: - Moving the group operations in a separate dialog - Including a new filter (by default) which includes all kinds of search keys (file name, workspace path, location, file length, modified/creation date, etc...). - More consistent with the other platform UI where the use can click in the UI on the 'Case sensitive' and 'Regular expression' check mark - Moving and renaming the 'Inheritable' check button as Martin's suggestion. - Re-working the add condition UI to make it more consistent with the general Eclipse UI. - New presentation for groups, where it shows with styled text in the tree view with the OR, AND, and NOT syntax).
Created attachment 163829 [details] Add new resource filter UI screen shot for the new resource UI
Created attachment 163830 [details] New add Group UI
Created attachment 163831 [details] Add new resource filter UI with keys
Note that the dialog now uses an (internally defined) custom UI per filter matcher ID. In the future, we could make a public API to allow 3rd party filter matchers to contribute a custom editor UI too.
Created attachment 163922 [details] Third change includes - 'Advanced...' button and dialog to select other filter matchers - Bug fixes, wording changes
Created attachment 163923 [details] Add new resource filter UI
Created attachment 163924 [details] Add new resource filter UI with keys
Created attachment 163925 [details] Advanced... dialog
Created attachment 163927 [details] New default matcher with rich key selection Shows how powerful is the new default matcher, where the user can enter different keys (for example, only show files that have been modified in the last 2 days).
Created attachment 164035 [details] Patch
The first comment is that we are restricted to java 1.4 only. And MultiMatcherCustomFilterArgumentUI doesn't follow this rule.
Created attachment 164040 [details] Patch Fix some jdk 1.4 compliance issue.
Comments: - 'Advanced' button on Edit Resource Filter may be confusing. I'm not sure why changing matchers is something more advanced. I would just put a list or a combo box at the top of the dialog here. - I would use two check boxes 'Files' and 'Folders' instead of three radio buttons - The horizontal line at the bottom should be attached to the button area. I'm not sure whether the line should have left/right margins or not. - I would add labels to sections, e.g. Mode, Details. Probably 'Include', 'Exclude' and 'Files', 'Folders', 'Apply recursively' should be next to each other.
(In reply to comment #19) > Comments: > > - 'Advanced' button on Edit Resource Filter may be confusing. I'm not sure why > changing matchers is something more advanced. I would just put a list or a > combo box at the top of the dialog here. I got the feedback from I don't remember whom that the combo box at the top (where it was before) was confusing and the user didn't know what it was for. Do you disagree with that statement, or would you have it somewhere else? > - I would use two check boxes 'Files' and 'Folders' instead of three radio > buttons Ok, I'll make that change. > > - The horizontal line at the bottom should be attached to the button area. I'm > not sure whether the line should have left/right margins or not. > I'll put the separator in the button section. There's a margin in other dialogs (search), but not in other (Preferences, new resource wizards). Some other dialogs don't even have separators (Open Resource). It's so messy I'm not sure what's the consistent way. Maybe Suzan can jump in? > - I would add labels to sections, e.g. Mode, Details. Probably 'Include', > 'Exclude' and 'Files', 'Folders', 'Apply recursively' should be next to each > other. Adding label is fine, but I removed them because I felt it made the dialog too crowded. Regarding the 'Apply recursively', martin actually suggested to put it below. Maybe a third opinion?
(In reply to comment #19) > Comments: > - I would use two check boxes 'Files' and 'Folders' instead of three radio > buttons Oh, actually, thinking about it, the problem is that by having two checkboxes, the user can no selection at all, while the valid selection is either 'Files', or 'Folders', or both, but not none. Enforcing this with checkboxes would invalidate the control design contract (basically, when only one is selected, you couldn't unselect it), so they'd behave half as radio button, half as checkboxes (when both are checked). While having 3 radio buttons works.
Created attachment 164141 [details] Patch now includes: - Re-formatted tree view hiearchy, with include and exclude filters grouped by kind. - Separator bar in the edit resource filter dialog now takes full width, and is in the button section.
Created attachment 164142 [details] New re-formatted tree hierarchy (simple example)
Created attachment 164143 [details] New re-formatted tree hierarchy (complex example)
(In reply to comment #24) > Created an attachment (id=164143) [details] > New re-formatted tree hierarchy (complex example) By the way, does anyone knows if it's possible to have the image in the StyledCellLabelProvider aligned in the center of the cell? I searched on the internet without success. Thanks,
(In reply to comment #20) > I got the feedback from I don't remember whom that the combo box at the top > (where it was before) was confusing and the user didn't know what it was for. I would say that we should be able to choose a matcher before we configure it. Thus 'Advanced' or combo should be above the matcher details. I'm not sure why combo is wrong here. > Do you disagree with that statement, or would you have it somewhere else? > > > - I would use two check boxes 'Files' and 'Folders' instead of three radio > > buttons You are right. We should leave it as it is now. > > - The horizontal line at the bottom should be attached to the button area. I'm > > not sure whether the line should have left/right margins or not. > > > I'll put the separator in the button section. There's a margin in other dialogs > (search), but not in other (Preferences, new resource wizards). Some other > dialogs don't even have separators (Open Resource). > > It's so messy I'm not sure what's the consistent way. Maybe Suzan can jump in? Right. I'm not sure either. > Regarding the 'Apply recursively', martin actually suggested to put it below. > Maybe a third opinion? On second thoughts, putting it below is fine. Other thoughts: - I would remove the 'Object' column. We should show the type of affected objects only at top-level nodes of the tree. - The same for the 'Recursive' column. We can actually configure it only for top-level nodes of the tree
(In reply to comment #26) > Other thoughts: > - I would remove the 'Object' column. We should show the type of affected > objects only at top-level nodes of the tree. > - The same for the 'Recursive' column. We can actually configure it only for > top-level nodes of the tree Forget this. I noticed that the tree structure is different now. I have to look at it again.
(In reply to comment #26) > (In reply to comment #20) > > I got the feedback from I don't remember whom that the combo box at the top > > (where it was before) was confusing and the user didn't know what it was for. > > I would say that we should be able to choose a matcher before we configure it. > Thus 'Advanced' or combo should be above the matcher details. > > I'm not sure why combo is wrong here. > What about putting it not in a combo box, but on a less intrusive widget, say, an down arrow (same as in the view toolbars) that pulls down a menu? The down arrow would be at the top left of the match UI block (between the include/exclude group and the matcher group)?
(In reply to comment #28) > The down arrow would be at the top left of the match UI block (between the > include/exclude group and the matcher group)? It could work. I think we could also show the name of the matcher being used. Then we would have to find a better name for the extended matcher. 'Default' is meaningless.
Created attachment 164211 [details] Some problems in the filters tree 1. When simple filters are copied between compound filters, wrong icon may remain. See the screenshot with a compound filter for files and its subfilters, one for folders and another for files. 2. The description at 'Include only' may be confusing since it does not contain details about types, i.e. files or folders 3. I would remove columns and place icons next to matcher descriptions. I'll attach a scrrenshot 4. I would rename 'Add condition' to just 'Add' in the context menu 5. Actions in the context menu respects the context, while 'Add' and 'Add Group' on the right side don't.
Created attachment 164212 [details] Szymon's proposal for the filters tree
Created attachment 164341 [details] Patch New in this patch: - Re-worked the TreeView UI, according to Szymon's proposal: only 1 column, icons before the text, no description in the 'include/exclude' node, etc... - Fix: "1. When simple filters are copied between compound filters, wrong icon may remain. See the screenshot with a compound filter for files and its subfilters, one for folders and another for files." - Fix: "2. The description at 'Include only' may be confusing since it does not contain details about types, i.e. files or folders" - Fix: "3. I would remove columns and place icons next to matcher descriptions. I'll attach a scrrenshot" - Fix: "4. I would rename 'Add condition' to just 'Add' in the context menu"
Created attachment 164343 [details] New re-formatted tree hierarchy
Created attachment 164363 [details] One more issue One more minor issue. We should add space between controls marked on the screenshot.
Created attachment 164439 [details] Latest Add resource filter dialog Showing: - The target (file/folder/file+folder) is now between the operation and condition, to match the tree view display, and follows the sentence INCLUDE-ONLY FILES under CONDITION - The matcher list is no longer displayed in an 'advanced' button, but under the down arrow button (it shows a popup menu). - the 'default' (multimatcher) has been renamed (the the user) as 'File and Folder Attributes'. - the dialog resizes automatically when another key is selected for the multimatcher and needs more space. - the radio buttons are aligned (not sure if it's a good thing yet).
Created attachment 164567 [details] Latest Add resource filter dialog this one is the right one
(In reply to comment #36) > Created an attachment (id=164567) [details] > Latest Add resource filter dialog > > this one is the right one Serge, could you attach a patch, so I could check how it looks on Win?
Created attachment 164582 [details] Patch
Created attachment 164809 [details] New Filters UI on Win XP I think the new UI looks good in general. There is an issue with spacing as marked on the picture. I think we could show the Exclude and Include nods always, even if such filters are not defined, similarly to Java Build Path/Source tab. Then the user could just select one of those two top-level nodes and click Add to add a filter of the selected type. Then we would not have to show the Operation block in the Add/Edit dialog probably. Serge, if I add my own filter matcher, would it be presented with the new UI correctly as yet another option in the Condition combo?
(In reply to comment #39) > Created an attachment (id=164809) [details] > New Filters UI on Win XP > > Serge, if I add my own filter matcher, would it be presented with the new UI > correctly as yet another option in the Condition combo? It will show up in the condition combo, and the condition UI will look the same as the 'String matcher' for now.
Created attachment 164836 [details] Final UI Now with the include/exclude implied from the selection in the tree.
Created attachment 164837 [details] Patch Addresses all raised issues.
Now fixed on head.
Congratulations Serge - this looks pretty cool! I haven't tried it out yet (just looked at the screenshot), and haven't read through all the comments... but one question that comes to mind is, when I press "Add..." on the filters page multiple times in succession, is it implicitly creating an "OR" group? The lower (exclude) part in your screenshot seems to imply that. Is the "AND" group in your upper part collapseable? It duplicates information.
(In reply to comment #44) > Congratulations Serge - this looks pretty cool! > Thanks Martin! > I haven't tried it out yet (just looked at the screenshot), and haven't read > through all the comments... but one question that comes to mind is, when I > press "Add..." on the filters page multiple times in succession, is it > implicitly creating an "OR" group? The lower (exclude) part in your screenshot > seems to imply that. > Yes, if the user repeatedly clicks on 'Add...', granted either 'include only' or 'exclude all' is selected, the items are interpreted as logical OR. For example, if the user has Include Only: Name matches *.c Name matches *.txt It will include only file whose name matches *.c OR name matches *.txt. In the UI, we though of putting a description besides the 'include only' node that showed the OR relation explicitly, but felt that it was displaying too much redundant information. At the moment, this rule is hinted by the text above the tree view '... matches *any* of the [...] filters..." > Is the "AND" group in your upper part collapseable? It duplicates information. Yes it is. It is collapsed by default. The Windows 7 tree widget doesn't show the collapsible arrow indicator when the tree view doesn't have focus, hence we can't see it on the screenshot.
Awsome - I'm impressed. Great work. And a proof of the value of having many eyes look at something.
There are many UI issues with the new version. Filed bug 309815 to polish this.
.
Verified in I20100429-1549
