Thoughts about statusbar

[Mark]

On Thu, Oct 27, 2011 at 2:59 AM, todd rme <toddrme2178 at gmail.com> wrote:

> 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.
>

I really like that last idea of an API there. Imagine an API like the
"Notification API" only for "status information" so i guess you can call
that "Status Information API". Then a plasmoid can be created to show status
information in whatever place the user finds useful.

How does mac solve this? They don't have a status bar and they seem to
manage just fine without it..

>
> Not a category, but redundant information (like in kcalc) should
> probably be removed as well.
>
> -Todd
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20111027/3a95d653/attachment-0001.html>