RE: Fwd: Guidelines for System Tray icons

Hi Troels,

On Fri, 2003-03-14 at 05:27, [email protected] wrote:

> >	From reading the KDE guidelines, one difference in opinion that is
> >obvious is that in GNOME we're tending towards the idea that an
> >application should always quit once you've closed all windows - it
> >should never remain "loaded" in the systray as this overloads the
> >meaning of the close window button and leads to a confusion over what
> >the button does.
> 
> This can indeed be confusing. I think the juk program (new in kdemultimedia
> in CVS) solves this nicely as it displays a dialog explaining that it is
> still running, and how you can quit it totally whenever you close the last
> window.

	Is that not just a dialog explaining what the user action just did,
though ? Should it not be obvious to the user what he just did - or to
put in another way, should it not be obvious what clicking on the close
button will do *before* he clicks on it ?

> This might not be the greatest solution, but IMO you render the traybar
> useless if you remove this feature.

	Is this the most important feature of the tray? Is the status
information provided by the icons not more important? It depends on your
interpretation of what the tray is, of course :-)

> Alternatively i guess it could be made so the programs in question could
> have a "hide windows" menu item (the actual wording needs work :), but this
> is really still doing the thing you complained about, just in a different
> way.

	You mean a "minimize" button ? :-) We have a fairly simple model now
with "close", "minimize", "roll up". Why add "hide to tray" ? Is that
not confusingly similar to minimize ? What's the benefit over mimize ?

> >  Some cases which make sense:
> >
> >	+ Applications which display an icon to inform the user of
> >	  current application "status", e.g. the number of unread
> >	  emails,
> 
> This example is bad. How can such a small icon display the number of unread
> mails? I think this would take an applet. Or would you make the icons able
> to be of variable width? The rest of the examples are fine.

	Well okay - its a call you have to make. Is the number of new emails
important, or is it just the fact that there are *any* new emails? I
would tend towards the former and suggest it might be good to have the
number of emails in a small label beside the icon. Of course, you don't
want to take up lots of space at some point you might decide to have

	== Eeek

	instead of

	== 1,893,649,345

	:-) Anyway, providing status information on your inbox is something
that I think we all agree on is a valid use case for the tray - quite
what is the best way of doing it is another thing ...

> >  Some cases which don't:
> >
> >	+ An application adds an icon to the tray when it starts. The
> >	  only "status" the icon shows is that the application is
> >	  currently running and the main purpose of the icon is
> >	  essentially to provide a shortcut to various application
> >	  operations without switching back to the application
> >	  itself.
> 
> I disagree here. (i dont know what to think of the thing about slow loading
> applications, i dont think i like the idea of that either)
> 
> Examples of trayicons i like: 

> i like keeping juk hidden, yet to have easy
> access to it through the tray icon. 

	What's wrong with just having it minimized ? 

> I like to see that the alarm daemon
> is running, yet i dont want a window. 

	Sorry, I don't know what the alarm daemon is - but maybe this is
something that *should* always be running. Have we not failed if we
require the user to make sure that is actually running ?

> I like being able to easily adjust
> the master volume by clicking on the kmix icon and adjusting the slider
> that pops up.

	We have an applet to do that in GNOME and I think that makes more
sense. If you do it this way, the icon turns into a "button with a
slider thingy" - but for consitency maybe these types of complex widgets
shouldn't belong in the tray. Also, is the volume  really "status" or is
it more of a configurable preference (you could argue about that :-)

> You might argue that these should all be applets, but my problem with that
> is that applets take up more room than the traybar icons, and if you want
> to move the icons then you have to do it one at a time, where as i can move
> the entire traybar in one go. (i use the quicklauncher applet for all my
> kicker buttons as well of the same reason about moving the icons around)
> And even if all these things were applets, then where would they show up?
> With trayicons they always appear in the traybar. Or do you expect the applets
> to always be present? I wouldn't need/want a juk icon when im not playing
> music for instance.
> 
> This is one of these instances where as a developer i find your arguments
> quite reasonable, but as a user i find them inconvinient as i find the current
> use of the traybar to both help save screen space and help me organize my
> panel, as well as provide convinient shortcuts and provides a way to make
> sure that a background daemon is running.
> 
> I see an applet as something that should present more than just an icon,
> like kmix can be displayed as an icon in the traybar, or you can start the
> mixer applet and have the mixer control sliders embeded directly in the
> panel. Another example could be an xmms trayicon that could hide/unhide
> the main window, and provide shortcuts to some of its feature, versus an
> xmms applet that would provide controls like play, stop, pause, etc, directly
> as buttons. (i even think such a thing exists)

	I don't think I'll respond to any of this in too much detail - I do
appreciate that these problems do exist (in GNOME too), but I don't
think the tray is the solution to all these problems.

	For example - I think providing some way of grouping of applets would
be useful. I don't think we should provide that feature my making
everything into a tray icon ... does that make sense ?

Cheers,
Mark.