This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
The search in the Tools/Options as introduced in bug #216311 does not seem to work properly. Examples: -after a start, open Tools/Options and type "import" into the Search box. Editor/Formatting is not listed as an option for me. -the search is not integrated with Editor/Hints category, and I don't see an API that I could use to integrate it. So the search does not search the content of Language panels in Editor/Hints. -when a search is performed, the current category/panel selection is not always kept. E.g. go to Misc/Files and type "Str" into the search box - "Editor" category is selected for me. -type "String" into the search box, and then delete it using backspace: I would expect that the result is that all categories&panels are visible, but that is not the case.
In addition to Honza's comment. On the Mac it looks really ugly.
Should be in upper right corner.
(In reply to comment #0) > The search in the Tools/Options as introduced in bug #216311 does not seem to > work properly. Examples: > -after a start, open Tools/Options and type "import" into the Search box. > Editor/Formatting is not listed as an option for me. > -the search is not integrated with Editor/Hints category, and I don't see an > API that I could use to integrate it. So the search does not search the content > of Language panels in Editor/Hints. This is mainly because there are many panels involved depending on the selection in the Language (and/or Category) comboboxes. Currently I only look into the default panels. Any suggestions on how I could get all the available panels? > -when a search is performed, the current category/panel selection is not always > kept. E.g. go to Misc/Files and type "Str" into the search box - "Editor" > category is selected for me. I will have a look into this > -type "String" into the search box, and then delete it using backspace: I would > expect that the result is that all categories&panels are visible, but that is > not the case. This is a bug and going to be fixed. (In reply to comment #1) > On the Mac it looks really ugly. This is true. Did not tested it on a Mac. Sorry for that, I will fix this (In reply to comment #2) > Should be in upper right corner. This was my first attempt, but it was messing with the top level categories (as they were disappearing/appearing) so it made more sense to add at the time it as an additional option at the bottom of the dialog.
(In reply to comment #3) > > -type "String" into the search box, and then delete it using backspace: I would > > expect that the result is that all categories&panels are visible, but that is > > not the case. > > This is a bug and going to be fixed. Fixed: http://hg.netbeans.org/core-main/rev/9180e27ee65a > > (In reply to comment #1) > > On the Mac it looks really ugly. > > This is true. Did not tested it on a Mac. Sorry for that, I will fix this This needed improvements on the QuickSearch side (cc-ing Martin): http://hg.netbeans.org/core-main/rev/a9a02508759a > > (In reply to comment #2) > > Should be in upper right corner. > > This was my first attempt, but it was messing with the top level categories (as > they were disappearing/appearing) so it made more sense to add at the time it > as an additional option at the bottom of the dialog. Fixed: http://hg.netbeans.org/core-main/rev/1cb184292ee3 Do you all think this is a better position for the search compared to the bottom left next to the Import/Export buttons?
> Do you all think this is a better position for the search compared to the > bottom left next to the Import/Export buttons? Afaik every dialog with search functionality has search field in upper part of the dialog.
(In reply to comment #3) > (In reply to comment #0) > > The search in the Tools/Options as introduced in bug #216311 does not seem to > > work properly. Examples: > > -after a start, open Tools/Options and type "import" into the Search box. > > Editor/Formatting is not listed as an option for me. > > -the search is not integrated with Editor/Hints category, and I don't see an > > API that I could use to integrate it. So the search does not search the content > > of Language panels in Editor/Hints. > > This is mainly because there are many panels involved depending on the > selection in the Language (and/or Category) comboboxes. Currently I only look > into the default panels. Any suggestions on how I could get all the available > panels? Might be good to let the Controllers do the filtering on their own (maybe with a default that would be similar to the current Swing hierarchy traversal). Possibly something as simple as: OptionsPanelController: /**true if the whole category should be filtered out.*/ public boolean filter(String filterText) { } I think that would work for Editor/Hints, did not look at Editor/Formatting yet. Would need to go through the API review, IMO.
Added support to give focus to search text-field on Ctrl+F : http://hg.netbeans.org/core-main/rev/3cc194442778
Just remarking that the current location of the search bar (in the bottom to the right from Import/Export buttons) indeed is questionable from UEX point of view. I agree with many previous comments that upper right corner would be significantly more intuitive and in line with conventions. However, it may not be straightforward to define how to change the Options dialog to permit that, thus I better add Rich to CC; so far I do not see a clear way forward. Points of concern: - search bar location (if moved to right top, where exactly? under the main categories bar? can we afford to increase the height of Options dialog?) - possible doubling of functionality as there are local search bars in some of Options panes - difference in behavior when compared to the main IDE search bar which also enables searching in Options (shortcut?, pre-filled grayed text "Search"?, immediate redrawing of dialog contents while typing might be perceived as disruptive by some users?) - maybe counter-intuitive way of resetting the full dialog state - by deleting search bar contents, what does not work always
All, I've got a few bits of feedback on this: a.) Yes, the top right is the appropriate location for this. It gets lost in its current position. b.) Metaphorically speaking, this isn't a search, it's a filter. It filters down the options to only things that match the search criteria. It should thus have a label in front of it that reads "Filter Options:", instead of the magnifying glass. c.) Pursuant to (b), there should also be a way to clear the filter. Currently, if I delete the value I typed, nothing happens...even if I exit the dialog and come back in, actually (I assume that's a bug).
Created attachment 122984 [details] options search in upper right corner Thank you for your comments (In reply to comment #8) > - search bar location (if moved to right top, where exactly? under the main > categories bar? can we afford to increase the height of Options dialog?) see screenshot. No reason to increase height, but we are increasing the width of the dialog. > - possible doubling of functionality as there are local search bars in some of > Options panes I do not think this is a problem (AFAIK this is done also in idea/eclipse). Currently for example I am using some hack to populate the search bar in Keymaps in order to filter the results. > - difference in behavior when compared to the main IDE search bar which also > enables searching in Options (shortcut?, added (see comment 7) >pre-filled grayed text "Search"?, not supported as currently this triggers search to start > immediate redrawing of dialog contents while typing might be perceived as > disruptive by some users?) no strong opinion about that. It can be changed to start search only on ENTER > - maybe counter-intuitive way of resetting the full dialog state - by deleting > search bar contents, what does not work always I think this is solved by the first fix in comment 4 (In reply to comment #9) > All, > I've got a few bits of feedback on this: > a.) Yes, the top right is the appropriate location for this. It gets lost in > its current position. > b.) Metaphorically speaking, this isn't a search, it's a filter. It filters > down the options to only things that match the search criteria. It should thus > have a label in front of it that reads "Filter Options:", instead of the > magnifying glass. I think this will make the dialog too wide. See current width in the screenshot. Could you suggest some other location where the search bar could be placed without negatively affecting the size of the dialog? This was my problem in the first place and I decided to place it next to the import/export buttons. But then there was the problem with "discoverability". > c.) Pursuant to (b), there should also be a way to clear the filter. > Currently, if I delete the value I typed, nothing happens... I think this is solved by the first fix in comment 4 >even if I exit the > dialog and come back in, actually (I assume that's a bug). This is indeed a bug, fixed: http://hg.netbeans.org/core-main/rev/5a540dfdf1f3
Re: positioning of the search box. I was actually thinking it could be in its own container above the "tabs" of the options dialog. This would signify that it applies to content on all tabs.
(In reply to comment #6) > Might be good to let the Controllers do the filtering on their own (maybe with > a default that would be similar to the current Swing hierarchy traversal). > Possibly something as simple as: > OptionsPanelController: > /**true if the whole category should be filtered out.*/ > public boolean filter(String filterText) { > } > > I think that would work for Editor/Hints, did not look at Editor/Formatting > yet. > Would need to go through the API review, IMO. My initial intention was to handle this without affecting the current implementation of each controller. Apparently this is not possible in all cases. Your suggestion looks promising. I could then ask each controller if the filterText is contained in them and make them visible/invisible accordingly. This would affect all clients as they would have to implement all the logic for searching into their Panels. If we do that we could probably eliminate the need for extra search bars in various panels (Keymaps, Editor/Hints) or we could keep them and add something like: OptionsPanelController: /**fills the local search bar (Keymaps, Editor/Hints) with filterText */ public void setLocalSearch(String filterText) { } so that I could set the text into the local search bars and have extra filtering when the user gives focus to those panels. all this will of course need API review
Created attachment 122992 [details] optoins search top (In reply to comment #11) > Re: positioning of the search box. I was actually thinking it could be in its > own container above the "tabs" of the options dialog. This would signify that > it applies to content on all tabs. I guess you mean something like this? We would need some extra vertical space though that in some cases we just do not have and we will get the same issues with vertical/horizontal scrollbars that we had for 7.2
(In reply to comment #11) > Re: positioning of the search box. I was actually thinking it could be in its > own container above the "tabs" of the options dialog. This would signify that > it applies to content on all tabs. I agree. And as for label, would it be enough to use just "Filter:" instead of "Filter Options:" because the latter seems to have a slight confusion potential, like if it was asking for some mysterious options to affect some kind of filter, of the like -Xss -Xm etc.
Petr, I'm fine with just "Filter:". And Theofanis, yes, that's the layout I am referring to.
Integrated into 'main-golden', will be available in build *201208110001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/a9a02508759a User: Theofanis Oikonomou <theofanis@netbeans.org> Log: Issue #216474 - Search in options not working properly - improving QS looks on Mac
Created attachment 123946 [details] Filter - no icon
Created attachment 123948 [details] Filter - with icon Regarding the removal of the magnifying glass please have a look at these two alternatives. Greyed out text can be added inside the text field to be consistent with the global quick search bar of the IDE. Which one do you think is the better approach? I will change the behaviour to only initiate the actual search on ENTER and make the components that need to be filtered-out disabled rather than invisible. Thank you
I think with the greyed-out filter text, its fine without the magnifying glass.
(In reply to comment #19) > I think with the greyed-out filter text, its fine without the magnifying glass. ok I would go with the latter image then (Filter - with icon) and just remove the magnifying glass. Thank you Rich.
Another issue is how should the Filter behave when quick search is confirmed (user presses ENTER). What I mean is this: The user types foe example "files" and presses ENTER. All categories or tabs that need to be filtered-out will become disabled. How should the user return to the default state (all categories/tabs enabled)? Currently he should give focus to the quick search and press ESC or ENTER with empty filter text. Do you have some other proposal on how to achieve this?
I think we can actually even go without the "Filter" label and just put the grey text "Ctrl-F to Filter" in the textbox...this has the added benefit of giving us extra width on that field. As for reverting a filter, there are two schools of thought: - deleting the filter and hitting Enter should clear the filter - Put a clear button to the right of the field, which clears the textbox and the filter. I prefer the second approach because it's more intuitive. It doesn't rely on the user having to know to clear the field and press Enter. It's a little uglier, admittedly. All in all, either option is fine.
Created attachment 124171 [details] various search/filter possibilities In my opinion the option with the clear button at the end gives poor results, especially on Mac (see filter_1_linux.png and filter_1_mac.png) On the other hand the option with the magnifying glass and the text (Filter (Ctrl+F)) is more appropriate, especially on Mac (see filter_2_linux.png and filter_2_mac.png) I would suggest we follow the latter case. Petr, Rich what do you think?
1) Added support to initiate the search/filtering only when the user presses ENTER. 2) Added some hint text which shows when the search text-field does not have the focus (similar to the global quick search). 3) Added tooltip giving instructions on how to clear the search/filter. 4) Regarding the position of the search/filter I do not want to waste vertical space so I went with the approach of the "options search in upper right corner" attachment but moved the search/filter all the way to the top. 5) Regarding the magnifying glass. As we are using the glass on Mac, I think it would be wrong to have different icon or no icon at all for Linux/Windows. So leaving that as is for now. http://hg.netbeans.org/core-main/rev/af1eafc5bf07
Theofanis, Sorry I'm just getting back to you, I was traveling back to the US all day yesterday. I think the Mac #2 screen grab you shared takes care of all of our use cases and looks nice. Is that implementable? Rich
(In reply to comment #25) > Theofanis, > Sorry I'm just getting back to you, I was traveling back to the US all day > yesterday. no problem > > I think the Mac #2 screen grab you shared takes care of all of our use cases > and looks nice. I agree >Is that implementable? I guess it can be done, but for the Mac case the only thing I do is to set certain properties for the search text-field and then the actual drawing is done automatically by the system (I do not have control over that). I do not think it worths the effort to try to mimic that behaviour for Linux/Windows and also various L&F. In any case, we are not making such effort for any other UI component or I am not aware of any.
minor fix for focus and clearing Keymaps search text-field when filter is cleared http://hg.netbeans.org/core-main/rev/43ef384b2161
Integrated into 'main-golden', will be available in build *201209160001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/af1eafc5bf07 User: Theofanis Oikonomou <theofanis@netbeans.org> Log: Issue #216474 - Search in options not working properly - start search on ENTER, added hint text
Fix for not hiding option panels but just disable them http://hg.netbeans.org/core-main/rev/b939f1d12784
Integrated into 'main-golden', will be available in build *201209180001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/43ef384b2161 User: Theofanis Oikonomou <theofanis@netbeans.org> Log: Issue #216474 - Search in options not working properly - fixed focus issue, clear Keymaps search issue
Integrated into 'main-golden', will be available in build *201209190001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/b939f1d12784 User: Theofanis Oikonomou <theofanis@netbeans.org> Log: Issue #216474 - Search in options not working properly - do not hide option panels, just disable them
After fixing bug 218312 I believe that I can close this one. If there are other cases where search does not work as expected please file a new bug. Thank you for all your comments.