Prev: java swing engine
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" :(

First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: java swing engine
Next: Looking things up by string prefix