[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-look
Subject:    Re: lowering the tab widget...
From:       "Friedrich W. H. Kossebau" <Friedrich.W.H () Kossebau ! de>
Date:       2001-03-09 16:00:00
[Download RAW message or body]


Dave Leigh wrote:
> On Tuesday 06 March 2001 18:14, Friedrich W. H. Kossebau wrote:
> > Everything that represents a handler (button, slider) is okay for me to
> > look like being higher than the rest. But the active frame is simply a
> > selected view nothing to handle directly so it should stay the level of
> > the whole window.
> 
> I'm not sure that this is what's intended to be represented.  There IS an
> active handler with a tabbed dialog... it's just that the handle (the tab) is
> connected to the rest of it.  You could think of it as a form of radio button
> that's attached to a frame (all one piece).  Clicking on the visible portion
> brings the whole tabbed page to the top. In fact, in the FoxPro world, before
> the tab widget was a standard toolkit item it was common practice for us to
> simulate it with a row of buttons physically adjacent to a bunch of
> borderless pages stacked on top of each other. Pressing a button simply
> indicated which page should be wontop().

Okay. So I have to find a way to separate the handler (tab) from the
page when developing an alternative solution I guess. There is this
selection list on upper or mostly left side (like in kwrite/settings)
but this is overkill with a few items (just like with radio buttons and
(push down) lists). What is interesting for me is that there is no
bordering of the page area like with tabbed pages. The only feedback
that the actual page belongs to the selection in the list is the
repetition of the title on the top. Maybe this is because the only usage
is in dialogs where the border is given by window and button bar.

But how often is a tabbed view used that really needs its own border? I
made a new 

> > I don't think a total flat look is helpful at all: Some light effects
> > help the eye to distinguish the different elements. As we can't event
> > totally new interaction elements we do fake some of the reality. As our
> > neuronal system is trained on these we have to adapt to this training
> > and make the elements look alike. Simple lines might look trendy
> > opposite to the traditional style where everything was given a
> > light-shadow look. But a little bit of surface modelling look is needed.
> > E.g. by using blendings.

I have to correct myself: Sometimes simple lines do their work too.
 
> I'm attaching a sample that might be a little easier to see.  It's a
> modification of your own, except that the inactive tabs are flat and the
> active one is raised.  I've colored one of the tabs as disabled, one active,
> the rest inactive.

Thanks for the work, but no, I don't think this solution acceptable as
the other tabs, which are still handles, don't like ones. And, of
course, because the whole page is still raised above the surrounding, on
a button's level. 
I like the one with buttons somehow, because the active page doesn't
need a handler, the others do. But it still doesn't look smart... :(
 
Friedrich

PS: I just saw that netscape's mail composing is the way I like:
embedding the tabbed views of adress, attachments and options! Perhaps
this is the way to go: embedding if it is only a part of a window,
removing extra borders when there is no need...
["noborder.png" (image/png)]

[prev in list] [next in list] [prev in thread] [next in thread]