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.
As discussed in : http://www.netbeans.org/servlets/BrowseList?listName=nbui&by=thread&from=8748 it seems like it would be nice to have NetBeans show only a single "active" selection (that is, so a user glancing at the interface can tell what thing is currently being operated upon).
Set target milestone to TBD
To be more precise ... The selection is rendered the same way no matter which window the focus is in. It would be helful if the selection could be rendered slighly differently in windows that don't have focus. This way the selection works as an additional visual feedback on focus. We believe that this will improve the learnability of NB in cases where users are unfamiliar with the active-node concept.
There's also precedent for this in the MacOS (at least the finder), and Windows (the explorer), Mozilla, and probably others. This seems to be an increasingly common pattern that NB should adopt.
ui -> core
FWIW, this is pretty easy to do in tree/table cell renderers - just see if the currently focused component is the thing being rendered and set the color accordingly. SheetTable in property sheet already does this for the purpose of appearing to have *no* selection unless it has focus (what would the user do with the selection there anyway?). The meta question is: - Is showing selection in a component that doesn't have focus actually useful for anything, or should there simply appear to be no selection? After all, you can't actually do anything with the selection without focusing the component, and information that is useless to the user is usually called noise...
To answer the meta question: It seems to be useful, because it tells people what will be focusd when they switch back to that view. This allows someone to glance at another view, and realize that all they need to do is to click on its title bar (or switch to it with the keyboard in the new window system) to then be able to operate on the item).
I agree w/ David John. If the tree is not focused, make the selection gray (like on Windows). Tim, you must listened on focus_gained/lost event and repaint accordingly. Please also consult this with Jano
Created attachment 11895 [details] Patch implementing this functionality
Integerated into trunk. C:\space\nb_all\openide\src\org\openide\explorer\view>cvs115 commit NodeRenderer.java TableSheetCell.java TreeTable.java Checking in NodeRenderer.java; /cvs/openide/src/org/openide/explorer/view/NodeRenderer.java,v <-- NodeRenderer.java new revision: 1.25; previous revision: 1.24 done Checking in TableSheetCell.java; /cvs/openide/src/org/openide/explorer/view/TableSheetCell.java,v <-- TableSheetCell.java new revision: 1.11; previous revision: 1.10 done Checking in TreeTable.java; /cvs/openide/src/org/openide/explorer/view/TreeTable.java,v <-- TreeTable.java new revision: 1.29; previous revision: 1.28 done Processing log script arguments... Mailing the commit message to cvs@openide.netbeans.org (from tboudreau@netbeans. org)
FYI, for the color when not selected, I used UIManager.getColor("controlShadow").brighter() (it does make sure it's non null, and use Color.GRAY if the look and feel doesn't supply a value for controlShadow, all though all the ones I know of do). If HIE has any suggestions for a prettier color, they are welcome.
Note (buried in mailing list archive): Metal L&F *already* displays focussed and unfocussed selections differently. The distinction just might not be obvious unless you are accustomed to it.
Seems to work fine for the Options window. But does not appear to work consistently in the 2nd panel of the Setup Wizard dialog. Sometimes it turns grey when you click e.g. in the description field, sometimes not. May be related to bug described in issue #29612. This (#18992) does however solve my issue #31002, sort of - now it is easy to tell when the TTV has focus or not, though the painting of the selected row in a focussed TTV is still wrong (missing dark blue border), making it look inconsistent with other Swing components.
I thought about adding the standard border for selection in TTV, then decided it was out of scope for this bug and should be done separately. I see what you mean with the second panel of the setup wizard; I tested it with the Import Management Tool, which heavily uses TTV. I'll see what I can do for the setup wizard. Bottom line is making this work is heavily dependant on repaint timing (note that with this patch when you click into explorer, it paints gray and immediately repaints blue). With TTV implemented as it is, a focus loss from the tree portion may trigger a repaint of the tree portion only. I solved this for SheetTable by not allowing the look and feel to add a focus listener (which would repaint only the selected cell), and instead installing my own which would repaint the entire selected row. Probably some similar hack is needed here, for better or worse.
Setup wizard now paints correctly. C:\space\nb_all\openide\src\org\openide\explorer\view>cvs115 commit TableSheetCe ll.java TreeTable.java Checking in TableSheetCell.java; /cvs/openide/src/org/openide/explorer/view/TableSheetCell.java,v <-- TableShee tCell.java new revision: 1.12; previous revision: 1.11 done Checking in TreeTable.java; /cvs/openide/src/org/openide/explorer/view/TreeTable.java,v <-- TreeTable.java new revision: 1.30; previous revision: 1.29 done Processing log script arguments... Mailing the commit message to cvs@openide.netbeans.org (from tboudreau@netbeans. org)
tried multiple select (Ctrl+A in Filesystems tab). The current node has different color than the non-current but selected items. Perhaps we should make them all have the same color.
My fix for this didn't handle multi-selection properly, so I'm reopening this issue until I fix that too. At the time I originally fixed this, I was told to simply fix it in the trunk. If this should be backported to some branch, which one?
Fixed properly in trunk this time.
Commit log. Now working on backporting to release35R. cvs commit: Examining . Checking in ListView.java; /cvs/openide/src/org/openide/explorer/view/ListView.java,v <-- ListView.java new revision: 1.71; previous revision: 1.70 done Checking in NodeRenderer.java; /cvs/openide/src/org/openide/explorer/view/NodeRenderer.java,v <-- NodeRenderer.java new revision: 1.26; previous revision: 1.25 done Checking in TableSheetCell.java; /cvs/openide/src/org/openide/explorer/view/TableSheetCell.java,v <-- TableSheetCell. java new revision: 1.13; previous revision: 1.12 done Checking in TreeTable.java; /cvs/openide/src/org/openide/explorer/view/TreeTable.java,v <-- TreeTable.java new revision: 1.31; previous revision: 1.30 done Checking in TreeView.java; /cvs/openide/src/org/openide/explorer/view/TreeView.java,v <-- TreeView.java new revision: 1.140; previous revision: 1.139 done Processing log script arguments... Mailing the commit message to cvs@openide.netbeans.org (from tboudreau@netbeans.org)
Merge to release35R: cvs commit: Examining . Checking in ListView.java; /cvs/openide/src/org/openide/explorer/view/ListView.java,v <-- ListView.java new revision: 1.63.22.1; previous revision: 1.63 done Checking in NodeRenderer.java; /cvs/openide/src/org/openide/explorer/view/NodeRenderer.java,v <-- NodeRenderer.java new revision: 1.22.28.1; previous revision: 1.22 done Checking in TableSheetCell.java; /cvs/openide/src/org/openide/explorer/view/TableSheetCell.java,v <-- TableSheetCell.java new revision: 1.7.2.1.18.1; previous revision: 1.7.2.1 done Checking in TreeTable.java; /cvs/openide/src/org/openide/explorer/view/TreeTable.java,v <-- TreeTable.java new revision: 1.24.2.1.4.1; previous revision: 1.24.2.1 done Checking in TreeView.java; /cvs/openide/src/org/openide/explorer/view/TreeView.java,v <-- TreeView.java new revision: 1.129.2.1.10.1; previous revision: 1.129.2.1 done Processing log script arguments... Mailing the commit message to cvs@openide.netbeans.org (from tboudreau@netbeans.org)
verified