HIG: tabwidgets

[Oswald Buddenhagen]

On Sun, Mar 12, 2006 at 03:30:51PM +1300, Thomas Zander wrote:
> On Sunday 12 March 2006 10:14, Aaron J. Seigo wrote:
> > > this directly conflicts with text editors' use of those. just like
> > > shift-arrow and shift-ctrl-arrow would.
> > > ... and alt-arrow is already taken for konq's history navigation ...
> > > too bad, we're screwed. ;)
> >
> > we could switch this to Ctrl-Arrow, so it harmonizes with text editors.
> 
> hmm? Thats next / prev word in a text area...
> 
harmonizes as in "then alt-arrow is uniformly free". of course this
assumes that a text field will never be found in a "history relevant"
context, which unfortunately does not work out as you point out below.

> > the downside here is that it would work if the location bar has focus,
> > but that's pretty  minor.
> 
> Well, if there is a textfield in a html page that tends to take initial 
> focus and the ctrl-arrow would not work there either...
> 
well, what should i say ... we are *thoroughly* screwed, then. :}

> I tend to like ctrl-< ctrl-> (as well as their non-shift versions ;) for 
> this better since most others are already taken...
>
that's a horror on german keyboards, as > is the shifted version of <. i
think using any "regular" key is risking such a thing with some
keyboard layout. you don't even want to know what ctrl-{} or ctrl-[]
would mean ...
fwiw, qt's default binding is ctrl-tab/ctrl-shift-tab - i think it's
logical, but it suffers the same problem as your ctrl-</-> suggestion.
it's no accel, though - it works only if the tab headers have focus.
not to mention that kde has this bound to switching desktops by default
in the 3-modifier layout.

ok, here are some constructive thoughs: :)
using some sort of left/right motion for backward/forward history
navigation is a very LTR way of thinking. and localizing it makes it
only more confusing. so i guess using alt-up (back) and alt-down
(forward) is a much better choice - at least i heard of no culture that
reads bottom-up. and it frees up alt-left/-right ... :)
i already hammered the kate & kdevelop dudes, now comes you: alt-<digit>
should immediately focus the correspondingly numbered tab (or window, to
extend it to mdi in general). alt-0 should pop up a list of available
tabs/windows. this also brings in what i read here a few days ago: on
the right side of the tab headers (between the navigation buttons and
the close tab button) should be a button to drop down a list of
available tabs (of course, it can be blended away if the tab headers are
wide enough, but this again leads to a dynamic ui) - alt-0 would be just
an accel for it.
dragging this further, an embedded second tab field (maybe a vertical
one) could use alt-shift-<digit> for direct focus. or maybe
alt-ctrl-<digit>, as on some layouts <digit> is already a shifted key
... damnit.
concerning vertical tabs, i see two use cases:
- they are embedded into a horizontal tab. then alt-up/-down for navi is
  ok, assuming such a construct won't need history navigation (would it
  be seriously used anywhere but in a config dialog?).
- they are stand-alone. then either still use left/right for navi (and
  confuse the hell out of users) or switch the meanings of left/right
  with up/down (making it even more confusing. lol).

hmm ... i've got an even better idea for history navigation:
conceptually it is the same as undo/redo, right? so just use
alt-backspace (undo)/alt-shift-backspace (redo), as reasonable text
editors do. :)

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.