On Thu, Oct 27, 2011 at 2:59 AM, todd rme <toddrme2...@gmail.com> wrote:
> On Wed, Oct 26, 2011 at 10:07 AM, Aaron J. Seigo <ase...@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@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel