Thoughts about statusbar

Thu Oct 27 10:07:21 UTC 2011

On Thursday, October 27, 2011 02:59:19 todd rme 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.

we already have KMessageWidget, and something similar to it could be provided 
for exactly these use cases. we also need people moving KDE apps to using 
KMessageWidget where apropriate, as an aside :)

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

knetwalk's level selection should be in the toolbar, the informaton in-canvas.
ultimately, the toolbar functoins could also be moved in-canvas as with most 
other games outside of KDE.

for okular, i'm sure there will be great pushback on this as the page 
navigation was a huge issue of contention in the past with the developers 
simply saying, "no, it will be this way." maintainer's perogative. however, 
since essentially no one is working on okular these days, it may be possible. 
otherwise, well .. you can't win them all :)

> 3. Status information (i.e. permanent information): information that
> is always visible in some form or another, like the time info in

this will likely have to be solved on a per-app basis. 

the games, for instance, should have all this information inline in the main 
game UI itself. nothing should live outside the game canvas that is important 
to playing the game.

in konversation, there is already a tab dedicated to each server, so the 
server status could move there (textually or graphically). numbers of people 
in a channel, lag, etc could be incorporated quite easily into other areas of 
the UI.

for other apps, the information is either redundant and can just be removed or 
could belong elsewhere in the UI that is more appropriate.

i don't think there can be a universal solution that is truly great for all 
apps, since the usage is so varied and there are many different ways of 
approaching it.

however, this category (3) of status bar usage could be expanded to help 
identify when the information is:

a) superfluous to the user (kmail's composer window)
b) useful, but should be put elsewhere
c) moving it elsewhere wouldn't result in any visual or usage improvements, so 
is justified in usage

with the three categories you outlined, and the third broken down into 3 
subcategories, i think we'd have something that could be formulated into a 
firm statement (i'd suggest doing something on community.kde.org to draft it, 
later if it becomes part of The KDE Way it could be moved to techbase). then 
we can get some of the interaction designers around KDE to look at it and 
offer suggestions and provide their support. then post an announcement to k-c-
d about the page, ask for feedback and then, and this is the most important 
part, start generating patches for applications to make them fall in line.

without that last part none of this is worth doing. :)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20111027/32279c44/attachment.sig>