On Thursday, October 27, 2011 02:59:19 todd rme 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.
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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel