Thoughts about statusbar

[todd rme]

On Wed, Oct 26, 2011 at 10:07 AM, Aaron J. Seigo <aseigo at kde.org> wrote:
> On Tuesday, October 25, 2011 17:37:57 Aurélien Gâteau wrote:
>> I disagree.
>
> i now officially regret letting this thread continue on this list.
>
> instead of keeping to the topic and seeing what conclusions might be derived
> and them moving it to a broader platform, here we are talking about what is or
> isn't workspace, telling each other how much people's efforts have sucked so
> far, blah blah blah blah... i'm severely disapointed.
>
> so:
>
> stop the meta-discussion. now. i have precisely zero problems unsubscribing
> people if necessary to achieve that.
>
> if anyone wishes to discuss the issue of statusbar usage, the original topic
> of this thread, do so now and bring this topic to a reasonable conclusion.
> then we can decide how best to get these kinds of changes vetted and made more
> broadly in KDE.

So lets try to put together the list of general current uses for the
statusbar, if this is the proper place for them, and if not where is
the proper place.  I'll list what I can think of off the top of my
head, but please add more (or better names, or split them into finer
groupings):

1. Short-term information display: this includes information that is
only displayed temporarily, such text when you mouse over something,
progress bars,. etc.  These could probably follow rekonq's model and
have something appear in the lower-right or lower-left corner of the
screen when needed rather than having a permanent bar.  Rekonq's
solution isn't themed very well IMHO, so having a KDE-wide way of
doing this with proper styling would help a lot.

2. Controls: buttons, usually.  This probably needs to be handled on a
case-by-case basis.  In cases like bangarang and gwenview where there
is a lot of such buttons making good use of space, they might be okay
(although some thought needs to be given as to whether they would be
better in the toolbar).  Cases with just one or two buttons, like
okular or knetwalk, should probably be moved into the toolbar.

3. Status information (i.e. permanent information): information that
is always visible in some form or another, like the time info in
dragon player, server info in konversation, game information in
knetwalk, free space in dolphin, etc.  This should probably be moved
elsewhere whenever possible.  Basic information text, like the server
in konversation or game info in knetwalk, would probably go in the
titlebar.  However, this could give problem for non-titlebar
interfaces.  Is there any way to provide a consistent API for status
text that could be displayed in a titlebar in interfaces that have
titlebars but be displayed somewhere else in cases where a titlebar is
not used?  In other cases there are already appropriate places for the
information, like the progress bar in dragon player could incorporate
the time information, and the places panel in Dolphin could display an
expanded free space bar for the current device.

Not a category, but redundant information (like in kcalc) should
probably be removed as well.

-Todd