[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-panel-devel
Subject: Re: Thoughts about statusbar
From: Mark <markg85 () gmail ! com>
Date: 2011-10-27 8:30:20
Message-ID: CAPd6JnEfVwNSayM_zDHYRHhvHgqx58XU9r28+Mx_C=Bqbp6Jrg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Thu, Oct 27, 2011 at 2:59 AM, todd rme <toddrme2178@gmail.com> wrote:
> On Wed, Oct 26, 2011 at 10:07 AM, Aaron J. Seigo <aseigo@kde.org> wrote:
> > On Tuesday, October 25, 2011 17:37:57 Aur=E9lien G=E2teau 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 wha=
t
> is or
> > isn't workspace, telling each other how much people's efforts have suck=
ed
> 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 ma=
de
> 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 statu=
s
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
>
[Attachment #5 (text/html)]
<div class="gmail_quote">On Thu, Oct 27, 2011 at 2:59 AM, todd rme <span \
dir="ltr"><<a href="mailto:toddrme2178@gmail.com">toddrme2178@gmail.com</a>></span> \
wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex;">
<div class="im">On Wed, Oct 26, 2011 at 10:07 AM, Aaron J. Seigo <<a \
href="mailto:aseigo@kde.org">aseigo@kde.org</a>> wrote:<br> > On Tuesday, \
October 25, 2011 17:37:57 Aurélien Gâteau wrote:<br> >> I disagree.<br>
><br>
> i now officially regret letting this thread continue on this list.<br>
><br>
> instead of keeping to the topic and seeing what conclusions might be derived<br>
> and them moving it to a broader platform, here we are talking about what is \
or<br> > isn't workspace, telling each other how much people's efforts \
have sucked so<br> > far, blah blah blah blah... i'm severely disapointed.<br>
><br>
> so:<br>
><br>
> stop the meta-discussion. now. i have precisely zero problems unsubscribing<br>
> people if necessary to achieve that.<br>
><br>
> if anyone wishes to discuss the issue of statusbar usage, the original topic<br>
> of this thread, do so now and bring this topic to a reasonable conclusion.<br>
> then we can decide how best to get these kinds of changes vetted and made \
more<br> > broadly in KDE.<br>
<br>
</div>So lets try to put together the list of general current uses for the<br>
statusbar, if this is the proper place for them, and if not where is<br>
the proper place. I'll list what I can think of off the top of my<br>
head, but please add more (or better names, or split them into finer<br>
groupings):<br>
<br>
1. Short-term information display: this includes information that is<br>
only displayed temporarily, such text when you mouse over something,<br>
progress bars,. etc. These could probably follow rekonq's model and<br>
have something appear in the lower-right or lower-left corner of the<br>
screen when needed rather than having a permanent bar. Rekonq's<br>
solution isn't themed very well IMHO, so having a KDE-wide way of<br>
doing this with proper styling would help a lot.<br>
<br>
2. Controls: buttons, usually. This probably needs to be handled on a<br>
case-by-case basis. In cases like bangarang and gwenview where there<br>
is a lot of such buttons making good use of space, they might be okay<br>
(although some thought needs to be given as to whether they would be<br>
better in the toolbar). Cases with just one or two buttons, like<br>
okular or knetwalk, should probably be moved into the toolbar.<br>
<br>
3. Status information (i.e. permanent information): information that<br>
is always visible in some form or another, like the time info in<br>
dragon player, server info in konversation, game information in<br>
knetwalk, free space in dolphin, etc. This should probably be moved<br>
elsewhere whenever possible. Basic information text, like the server<br>
in konversation or game info in knetwalk, would probably go in the<br>
titlebar. However, this could give problem for non-titlebar<br>
interfaces. Is there any way to provide a consistent API for status<br>
text that could be displayed in a titlebar in interfaces that have<br>
titlebars but be displayed somewhere else in cases where a titlebar is<br>
not used? In other cases there are already appropriate places for the<br>
information, like the progress bar in dragon player could incorporate<br>
the time information, and the places panel in Dolphin could display an<br>
expanded free space bar for the current device.<br></blockquote><div><br></div><div>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. </div>
<div><br></div><div>How does mac solve this? They don't have a status bar and \
they seem to manage just fine without it..</div><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Not a category, but redundant information (like in kcalc) should<br>
probably be removed as well.<br>
<font color="#888888"><br>
-Todd<br>
</font><div><div></div><div \
class="h5">_______________________________________________<br> Plasma-devel mailing \
list<br> <a href="mailto:Plasma-devel@kde.org">Plasma-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/plasma-devel" \
target="_blank">https://mail.kde.org/mailman/listinfo/plasma-devel</a><br> \
</div></div></blockquote></div><br>
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic