Re: Fwd: Guidelines for System Tray icons

Putting open-hci back into CC ...

I think the main problem with apps like kopete and juk is, that the main=20
window is not the real representation of the application. IIRC in the KDE=20
Styleguide it says, that the (main) window is the application, so it would=
=20
probably be correct to only allow usage of the system tray as notification=
=20
area.

On the other hand, those daemon-like applications (you can also add kradio =
to=20
these) are poorly represented by a main window, because their main function=
=20
is not to interact with the user all the time and their windows do not=20
represent documents in the classical sense either.

To be usefull those applications should be able to run without showing a ma=
in=20
window at all. This is what the system tray is used for at the moment.=20
IIRC on MacOSX a window is just a window, and not the application. They hav=
e=20
the dock where they show the running applications and minimized windows.=20
Clicking on a running app shows a hidden window or opens a new one (again,=
=20
IIRC).

In KDE (and Gnome AFAIK) all windows are listed and marked when they are=20
minimized. When a window is closed because the user does not need this wind=
ow=20
any more and does not want it to clutter his list of open windows, the=20
application closes as well and the music stops - unless the system tray is=
=20
used to keep the application running. We have no distinction between=20
application and main-window.

If we stay with the main-window =3D=3D application rule and forbid apps to =
use the=20
system tray for interactions other than status display, a user is forced to=
=20
always have some main windows in his window list (example: for me that woul=
d=20
mean kradio, juk, kopete, kget, kgpg), even though one wants to usually=20
forget about those apps when working with important documents.

If the solution should be based on using applets instead of the system tray=
,=20
then IMHO we need to remove the distinction between applets and application=
s=20
in the menu - which opens another can of worms... And one application needs=
=20
to be able to have an associated applet which is started by the application=
 -=20
and runs in both the Gnome and KDE panels).

Am Freitag, 14. M=E4rz 2003 12:32 schrieb Luke Chatburn:
> It seems to me that we are getting confused because the line between a us=
er
> process and a system one is getting blurred. To me, a jukebox seems to be=
 a
> user-centric program that doesn't belong in the sytem tray, simply because
> it has nothing to do with maintaining the system; it is a program that is
> there purely to interact with the user (produce music for their listening=
).
>
> Here is a thought on this...
>
> What if the system tray was moved from being a separate hide-able applet
> into a taskbar entry, labeled 'System', which operates like a task group
> (such as the way Konqy windows group together), except for the fact that
> the application icons appear in the top entry? Colour the System button
> differently or something, maybe. Then when you click and hold, it springs
> down a menu of the sys. tray programs, with their names beside them. This
> ought to be nicer than just having the icons, which are confusing 'What
> program does this icon represent?'.
>
> This would see the taskbar becoming a one-stop-shop for 'programs which a=
re
> currently running', services (Apache, etc.) notwithstanding. At the end of
> the day, most users don't understand the difference between taskbar apps
> and system tray apps (and this ambiguity is even confusing us at the
> moment), so let's just say 'These are all the apps running, and btw, here
> are the ones the system has for you, too.'
>
> I think the idea of minimising to the system tray is a problem, because we
> are migrating applications between two different conceptual areas.
> Honestly, I think that the system tray is a bad idea, but there it is; if
> it and the taskbar were conceptually so different, we shouldn't be able to
> shove applications back and forth between them to start with.
>
> If you wanted to be really useful, you could add a sub-menu at the bottom
> of the system tray list in the taskbar with 'Services', which showed the
> status of Apache, Samba and other services, with the option to stop and
> start if the user has privilages.
>
> I would like to never have to talk someone through things on the phone:
>  'Go to your system tray...'
> 'What's that?'
> 'If you look in the bottom right-hand corner of the screen, you'll see so=
me
> icons'
> 'Okay...'
> 'Now, look for the one which looks like <icon desc.> and right-click it'
> 'Okay...'
> 'What option do you see?'
>
> etc. It should be noted at this point that most users will left-click it
> instead, even if you tell them to right-click, because they aren't famili=
ar
> with what that does.
>
> -Luke
>
> ----- Original Message -----
> From: "Mark Hillary" <[email protected]>
> To: <[email protected]>
> Sent: Friday, March 14, 2003 10:36 AM
> Subject: Re: Fwd: Guidelines for System Tray icons
>
> Hi,
>
> I have just been lurking on this list, but want to make some input here.
>
> On Thursday 13 Mar 2003 5:27 pm, Klas Kalass wrote:
> > > 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.
> >
> > Just for the record and because Martijn is certainly listening: that
>
> dialog
>
> > was pretty much copy-paste from Kopete :-)
>
> Personally I like applications that can be minimised to the system tray.
> This
> works well for GUI applications that are going to be running all the time
> and
> need very little user interaction, like an mp3/ogg player or an IM progra=
m.
> Having them in the taskbar is not really appropriate because they are not
> user tasks but running in the background. Sometimes the user needs to
> interact with the application to do something like change song, log out of
> the IM network.
>
> I don't think having them as separate applets gains anything other than
> confusion. The user would end up with two groups of icons, probably right
> next to each other, and think why can't they be is the same place. It wou=
ld
> appear disjointed.
>
> The behaviour of minimising to the system tray should not be the default
> behaviour. The application should either just minimise to the taskbar, or
> have an icon in the systray and minimise to the taskbar. The user should
> then
> be allowed to change this behaviour if they want, and inform the exactly
> what
> the application is doing.
>
> Mark Hillary
>
> _______________________________________________
> kde-usability mailing list
> [email protected]
> http://mail.kde.org/mailman/listinfo/kde-usability

=2D-=20
Geektalk from the Mandrake Cooker mailing list:
=20
Subject: Re: [Cooker] What happened to the program "more"?

It was probably replaced with less, which is more or less more, but a bit m=
ore=20
(a.f.a.i.k). Paul.