Nimbus JTabbedPane shuffles tabs
in [Java Programming]
|
Prev: Urgent Openings: 1.GIS Web Developer(.Net), 2.Business System Analyst, Austin, TX., 3.Maximo positions
Next: Looking things up by string prefix
From: FutureScalper on 2 Jul 2010 11:17 On Jul 2, 9:15 am, markspace <nos...(a)nowhere.com> wrote: > FutureScalper wrote: > > Thanks for the tips, but I want the tabs to wrap and stack. I just > > don't want the row stacking order to change. > > Huh, how does that actually work? If you have some rows of tabs and one > is displaying: > > / Tab 1 \/ Tab 2 \/ Tab 3\ > / Tab 4 longer name \ | > / Tab 5 \/ Tab 6 \ | > | -----------------| > | | > | Tab 5 | > | | > | | > +-------------------------+ > > Now you want to see tab two, it won't be connected to the display pane > if you display it it without reordering. I think this would be very > confusing to the users. > > / Tab 1 \/ Tab 2?\/ Tab 3\ > / Tab 4 longer name \ | > / Tab 5 \/ Tab 6 \ | > |-------------------------| > | | > | Tab 2 | > | | > | | > +-------------------------+ > > Not sure I like that. And I don't think anyone would write code to make > it work that way, so I think you're on your own. Maybe subclass tabbed > pane and redo the tabs. Might be able to fake them with buttons and a Box. All that I am asking for is that it work like this one works: -Dswing.defaultlaf=com.sun.java.swing.plaf.windows.WindowsLookAndFeel - Dswing.metalTheme=steel This does NOT re-order tabs simply as a result of an individual tab being selected. Re-ordering tabs seems odd (to me) as a GUI principle. Unless there is some reason that a row needs to be re-ordered "closer" to the tabbed pane, then this forces the user to "hunt" for the re-ordered information, rather than to be able to rely upon the cluster of tabs remaining in a fixed configuration. Naturally, this is debatable. Would be best if a Layout Policy could be set NOT to re-order wrapped rows of tabs, simply as a result of tab selection. Tab order should be tied to the order in which the code adds tabs to the JTabbedPane, or at least that should be an option. I will dig into the code and see whether I can over-ride the behavior, as one poster suggested. THANKS FOR YOUR HELP.
From: FutureScalper on 2 Jul 2010 11:20 On Jul 2, 9:15 am, markspace <nos...(a)nowhere.com> wrote: > FutureScalper wrote: > > Thanks for the tips, but I want the tabs to wrap and stack. I just > > don't want the row stacking order to change. > > Huh, how does that actually work? If you have some rows of tabs and one > is displaying: > > / Tab 1 \/ Tab 2 \/ Tab 3\ > / Tab 4 longer name \ | > / Tab 5 \/ Tab 6 \ | > | -----------------| > | | > | Tab 5 | > | | > | | > +-------------------------+ > > Now you want to see tab two, it won't be connected to the display pane > if you display it it without reordering. I think this would be very > confusing to the users. > > / Tab 1 \/ Tab 2?\/ Tab 3\ > / Tab 4 longer name \ | > / Tab 5 \/ Tab 6 \ | > |-------------------------| > | | > | Tab 2 | > | | > | | > +-------------------------+ > > Not sure I like that. And I don't think anyone would write code to make > it work that way, so I think you're on your own. Maybe subclass tabbed > pane and redo the tabs. Might be able to fake them with buttons and a Box. In my view it's not "connected" to the display pane because its row is shifted down. It's "connected" or, rather "selected" because the tab itself is highlighted, indicating it is selected. You're thinking of proximity, I guess, but that is at odds with a consistent spatial positioning. I'm arguing for fixed spatial positioning of the tabs, unless something forces a layout change.
From: FutureScalper on 2 Jul 2010 11:29 On Jul 2, 11:20 am, FutureScalper <futurescal...(a)gmail.com> wrote: > On Jul 2, 9:15 am, markspace <nos...(a)nowhere.com> wrote: > > > > > > > FutureScalper wrote: > > > Thanks for the tips, but I want the tabs to wrap and stack. I just > > > don't want the row stacking order to change. > > > Huh, how does that actually work? If you have some rows of tabs and one > > is displaying: > > > / Tab 1 \/ Tab 2 \/ Tab 3\ > > / Tab 4 longer name \ | > > / Tab 5 \/ Tab 6 \ | > > | -----------------| > > | | > > | Tab 5 | > > | | > > | | > > +-------------------------+ > > > Now you want to see tab two, it won't be connected to the display pane > > if you display it it without reordering. I think this would be very > > confusing to the users. > > > / Tab 1 \/ Tab 2?\/ Tab 3\ > > / Tab 4 longer name \ | > > / Tab 5 \/ Tab 6 \ | > > |-------------------------| > > | | > > | Tab 2 | > > | | > > | | > > +-------------------------+ > > > Not sure I like that. And I don't think anyone would write code to make > > it work that way, so I think you're on your own. Maybe subclass tabbed > > pane and redo the tabs. Might be able to fake them with buttons and a Box. > > In my view it's not "connected" to the display pane because its row is > shifted down. > > It's "connected" or, rather "selected" because the tab itself is > highlighted, indicating it is selected. > > You're thinking of proximity, I guess, but that is at odds with a > consistent spatial positioning. > > I'm arguing for fixed spatial positioning of the tabs, unless > something forces a layout change. Imagine a user wants to click through all of the tabs, from upper left down through lower right. But this results in operator error when the rows keep shifting, and the user must visually "hunt" for the tab she wishes to click. 1, 2, 3 is the first row, 4, 5, 6 the second 7, 8, 9 the third. But, woops! when 1 is clicked, it suddenly moves 2 rows down (assuming tabs at the top of the display area), swapping rows with what was the third row. From a human factors perspective, perhaps not so good. And, for a fixed layout, a given functional tab, I would suggest, should always be in the same location. Now, there might be exceptions to the rule but, for me, it has always been confusing when tabbed rows suddenly change their row rankings because I selected a tab in that row and it was non-adjacent to the displayed panel area.
From: John B. Matthews on 2 Jul 2010 14:48 In article <737f986b-4e2a-4e5e-8a17-710b11b794cf(a)e35g2000vbl.googlegroups.com>, FutureScalper <futurescalper(a)gmail.com> wrote: > I will dig into the code and see whether I can over-ride the > behavior, as one poster suggested. It looks like MetalTabbedPaneUI.TabbedPaneLayout achieves the effect you want by overriding the methods rotateTabRuns(), padSelectedTab() and normalizeTabRuns(). These methods are inherited from the superclass BasicTabbedPaneUI.TabbedPaneLayout. -- John B. Matthews trashgod at gmail dot com <http://sites.google.com/site/drjohnbmatthews>
From: FutureScalper on 3 Jul 2010 10:39
On Jul 2, 2:48 pm, "John B. Matthews" <nos...(a)nospam.invalid> wrote: > In article > <737f986b-4e2a-4e5e-8a17-710b11b79...(a)e35g2000vbl.googlegroups.com>, > > FutureScalper <futurescal...(a)gmail.com> wrote: > > I will dig into the code and see whether I can over-ride the > > behavior, as one poster suggested. > > It looks like MetalTabbedPaneUI.TabbedPaneLayout achieves the effect you > want by overriding the methods rotateTabRuns(), padSelectedTab() and > normalizeTabRuns(). These methods are inherited from the superclass > BasicTabbedPaneUI.TabbedPaneLayout. > > -- > John B. Matthews > trashgod at gmail dot com > <http://sites.google.com/site/drjohnbmatthews> Thanks John for the tips on possible code workarounds. This app is a high performance online Futures trading application and I can't afford "operator error" due to the GUI arbitrarily reorganizing itself. So I may try and work around it, or just stay with what I have, or find another LAF which does not do this. All I wanted to do was to "skin" it a bit, and I found myself in all of these "gotchas" :( |