[Panel-devel] System tray

[Lubos Lunak]

On Thursday 30 of June 2005 20:06, Aaron J. Seigo wrote:
> On Thursday 30 June 2005 08:24, Lubos Lunak wrote:
...
> > 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.

 My patches then clearly are not good for this, for these and more reasons.

> > - if KNode suddenly starts showing number of messages too, is it suddenly
> > ok for it be minimized to the tray too?
>
> sure.
>
> > - 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.

 I see. KNode is no service, but it starts showing a number of messages and it 
suddenly is, with all the consequences.

> > - 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.

 Ok, this seems to be my mistake, so you don't intend to use the systray for 
what the applets are a better fit. Even though AFAICS a CPU monitor perfectly 
fits your description belong of what the systray should be.

> > > , 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.

 You're doing a good job too. I don't remember having ever talked about 
KMail's applet. KMail's always been case 1) systray icon with a mainwindow 
associated, which should be moved to the taskbar, not case 2) applet-like 
systray icons where the mainwindow is the icon itself, which should become 
applets (in my proposal at least). No DCOP or anything like that, no 
complexity added.

 In fact, given you cpu monitor comment, we probably agree on my 2). It's just 
that you still don't get what I mean with 2) and keep refusing it because of 
arguments based on things that don't belong to 2) at all.

> > > 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.

 Well, don't worry anymore, I give up. We seem to have some fundamental 
misunderstanding or a communication problem or whatever. You don't get what I 
say, I apparently don't get what you say, this is leading nowhere. You're the 
boss, do whatever you want with the systray.
 
> > - 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.
>
> > > 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

 With the current status of everybody being confused about the purpose of the 
systray, I'm sure it will be suddenly clear with such good description like 
this and examples like the KNode one.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/