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

List:       kde-usability
Subject:    Re: the "terminal sessions" kicker button behaviour...
From:       "Friedrich W. H.  Kossebau" <Friedrich.W.H () Kossebau ! de>
Date:       2004-02-18 21:46:06
Message-ID: 200402182246.06881.Friedrich.W.H () Kossebau ! de
[Download RAW message or body]

Am Mittwoch, 18. Februar 2004 15:27 schrieb Aaron J. Seigo:
> On February 18, 2004 05:04, Friedrich W. H.  Kossebau wrote:
> > > i didn't mean KActions. i meant "actions" as a generality, as in "i'm
> > > going to take an action". many applets are not of the "hit a button and
> > > something in specific happens" nature that embodies what toolbars are
> > > for.
> >
> > But many are: close my session, start the screensaver, start this app,
> > switch to desktop x, switch to window y, control the volume, stop
> > playing, start playing, ...
>
> many, but not even nearly close to all. look at the systray for another
> example. i'll add a different example to each reply if necessary ;-)

No need to ;), I know that myself, wanted only to stress that indeed a lot 
_are_ actions. Like there are toolbar items which are _not_ actions.

> > But I guess it all ends with what we think "toolbars are for". I
> > understand you to only want buttons on the toolbar (which might only work
> > for simple apps IMO)
>
> no, that isn't what i want at all.
>
> > Which is your reasoning to _restrict_ to buttons? Esthetical? A mouse as
> > a simple one-button tool?
>
> you've missed my point COMPLETELY. =) i'm not saying "toolbars should have
> only buttons" i'm saying "kicker is a LOT more instrumented and dynamic
> than toolbars ever will be".

Which is what I deny: neither "LOT"  nor "ever will be". Once again the point 
where we split. 
I see I do not have the slightest chance to convince you about this reasoning 
to give the user the same feel for the desktop's toolbar, err, the panel like 
an apps toolbar has. I give up. 

> toolbars are relatively static holders shortcuts for actions .. users can
> determine which actions appear there with hopefully sensible defaults.
> kicker provides access to a much broader array of elements, and is by
> design far more dynamic.
>
> > > > >  o contains menus
> > > >
> > > > Some toolsbars do too.  For instance the back button in konqui shows
> > > > a drop-down menu if click+hold, but goes back immediately when just
> > > > clicked. There are more such buttons showing an optional menu.  I
> > > > think this would be the appropriate behaviour of similar buttons in
> > > > kicker.
> > >
> > > the menubar applet in kicker; or the applet handles; or... the panel is
> > > far more complex and instrumented than a simple toolbar is (or at
> > > least, should be).
> >
> > Now, is it? Why do you have to use the attribut "simple"? So toolbars are
> > not simple in itself? Why do you add "should be"?
>
> i add "should be" because toolbars lose their usefulness when they become
> too complex. a toolbar is not a tool_box_ (e.g. photoshop's toolboxes).

Hehe, for me it is. A toolbox lined up in one row looks like...? a toolbar. 
And is. At least for me.

> > My panel looks much less complex than KDevelop's or KOffice toolbar
> > "mess"...
>
> that's right, they are a mess. but again you miss the point: if koffice's
> toolbars are cluttered, they are still filled with actions. the
> interactivity and complexity model is very different between a toolbar and
> the panel.

Perhaps my view is more abstract than yours. I find the same model over and 
over. One day I take the time and make up some docs (have exams these days). 
For now I tried what I could do. Period :)

Friedrich
_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]