[Panel-devel] System tray

[Aaron J. Seigo]

On Thursday 30 June 2005 08:24, Lubos Lunak wrote:
> systray icon is fine [4], because it shows the number of mails. Brings up a
> number of interesting questions, like
> - if KNode suddenly starts showing number of messages too, is it suddenly
> ok for it be minimized to the tray too?

sure.

> - how about Licq, which shows status too, but only uses the icon for it,
> which is something the taskbar can do as well?

yes, i think this is fine

> - and how about media players, CD burners and similar? Where do you want to
> draw the line (no, I haven't found any place where you'd say it)?

you and i actually talked about this exactly example on IRC a couple weeks 
ago. i mentioned how kaffiene's icon is silly since there's no reason to have 
an interface for a video player (which you need to _see_ to be useful) in the 
systray, but having something for an audio player which can be considered a 
"service that plays audio in the background" can make sense.

>  Or, another case, you say that you don't want systray to be only for
> minimizing, but when I posted my patches [5] saying they implement 1) in my
> proposal [6], i.e. minimizing to tray basically, you say you like the
> patches [7].

yes, i like how it moves us away from XEmbed while keeping backwards compat. i 
don't like the minimizing and i've said that a few times. i can like certain 
aspects of it and not others.

> you at the same time seem to want to move the minimize-only cases to
> taskbar [8] but then you say that actually wouldn't quite work because that
> would require the taskbar to be always there [9] and that it should be
> separate.

if you read 9 a bit more carefully you'll see that i'm talking about the popup 
menus as primary interface via the taskbar, not the simple case of "just 
minimize and show an icon in the systray".

> systray[6], yet you don't like my proposals how to solve it and I don't see
> anywhere how you would like to solve them.

i'd like to see it solved by having a some simple IPC done between 
applications and the systray. i don't want it to require an X window, and i 
don't want any XEmbed'd widgets.

> - what do you want to do with those you don't want in systray (and how do
> you want to achieve that, just ask the authors to be nice)?

i don't think we can ever fully lock out clever programmers, but we can 
certainly educate them, yes.

> - how do you want to solve the close button mess, with some apps quiting
> and some not (I hope you see a certain problem with "solving" it using the
> "this app will actually not quite, it will just hide, got it?" and "are you
> really sure you want to quit?" dialogs)?

this is the whole "what is a service, and what isn't" disccusion all over 
again. "services", which are capabilities that are not tied to a window (e.g. 
instant messaging, audio players) ought not quit until all elements are 
dismissed. every thing else which is tied to a specific, usually visual, 
context and meaningless without it should behave like any other 
window-centric app.

> - you're perfectly fine with having two completely different ways of
> implementing e.g. a CPU monitor for the panel?

if you're asking if the systray is the right place for a cpu monitor, i don't 
think so, no. i also don't see a way to stop that from hapenning by policy 
that doesn't make other valid uses impossible at the same time, however.

the best we can do is not ship such a thing with kde.

> - you don't mind the inability to rearrange some items on the panel as the
> user wants?

that's correct. and if anyone thinks this is some horrible problem, then take 
a look around at the GUI and ask:

	o how many other things can't i change?
	o does it really impact my life as a user or am i just going after some 
puritanical desire for ultimate flexibility because i can?

> > , take more time for developers (note how i'm
> > always trying to make things easier for people who would like to make KDE
> > better?)
>
>  Like, by giving them two ways of doing things? You said in one of the
> mails in the threads that something (KNetLoad or whatever, I don't
> remember) is a systray icon instead of an applet because that was simpler
> for the developer. Sadly, I can't find that post right now, and I also
> can't find a post somewhere by an author of similar (or even this) utility
> where he said he had converted his network monitor systray to an applet,
> which was fine, except that it doesn't work without KDE now. People don't
> prefer writing systray apps to applets because it's simpler or whatever,
> they do that because it's more portable.

once again you are taking what i say and changing the context. good job!

when i've talked about simple vs hard i've been discussing it in the context 
of things like kmail which would, were they to use a panel APPLET versus a 
systray ICON, mean that they would have to set up a DCOP communication 
between the applet and the application and manage starting/stoping the 
applet. it would also be another lib for them to install and probably 2-3x 
the LOC for the applet vs the icon.

this IS more work. i'm sorry if you don't care about that, but i do. if we 
make 10 things 5% harder, KDE becomes too difficult to develop for, where 
"too difficult" means "more effort than most are willing to put in"

> > ... regular applets would need to communicate with the main
> > application in some way, most likely DCOP, and that's yet more overhead
> > for the developer.
>
>  Most applets can do fine without any additional app. And, since you want
> systray to be IPC, applets doing IPC is wrong, systray doing IPC is fine

"applets doing IPC is wrong" -> "applets doing IPC is not optimal"

and if you sit back and think about it for a few minutes the reasons ought to 
be pretty freakin' obvious.

> > BUT all of this is ballanced against the MOST important
> > point which you constantly forget to add:
> >
> > 	moving them out of the systray doesn't substantially fix anything
>
>  Last time I checked, everybody thought systray was a random mess that
> sucked in various ways, and we had two ways of adding applets to the panel.

well, no shit sherlock! god this conversation is really starting to try my 
patience.

the sytray is a random mess. some of the icons in the systray DON'T belong 
there, either because they SHOULD be applets or because they are just using 
it as a place to minimize or because it's just plain silly (see kaffeine).

that doesn't have anything to do with the concept that if we simply relocate 
all the systray icons that are valid out of the systray to the panel that all 
we are doing is relocating that set of challenges.

in other words you're taking what is IMHO a valid point and answering it with 
another completely valid point but which has NOTHING to do with the first 
point. please... 

> > i don't know how many times i can say this before just throwing my hands
> > up in the air and giving up completely on the matter. this is now
> > probably the 4th or 5th forum in which i've communicated this. what part
> > is difficult to understand?
>
>  See above. For the 4th or 5th time, I think the basic problem is that
> nobody has really specified what the systray is.

here's my take:

it should be a place to put continuous informational feedback representations 
and provide small light-weight interfaces to running services that otherwise 
may not be available via a GUI.

continuous informational feedback -> that's something that needs to be shown 
all the time and so is not a candidate for a passive popup (e.g. your unread 
mail count). a hallmark of these items is that they aren't driven by events 
but are equally important during periods of no events.

services -> capabilities which, from a user's perspective, are not tied to a 
window 

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20050630/56d720cd/attachment.pgp