[Panel-devel] System tray

Lubos Lunak l.lunak at suse.cz
Thu Jun 30 16:24:27 CEST 2005


On Thursday 23 of June 2005 19:12, Aaron J. Seigo wrote:
> On Thursday 23 June 2005 08:45, Lubos Lunak wrote:
> >  IMHO technical aspects are actually the last thing to be discussed ...
> > well, or at least not the very first. It's been at least three times that
> > I got various new understandings of what Aaron does (or doesn't) want to
> > do with the systray.
>
> well, i've been fairly consistent about what i've been saying. you can read
> my blogs on the matter, the page on my website on the matter and the
> threads on kde-core-devel .. i've stuck pretty close to what i've said all
> along.

 Well, nobody says it can't be a problem on my side. I actually bothered to 
read again all Aaron Seigo posts in the kde-core-devel "systray*" threads, 
searched the blog for "systray" and "tray" and also checked the mentioned web 
page (I presume that's supposed to be [1]) and also the IRC logs. And I'm 
afraid I still don't quite get it. It's not that you wouldn't be consistent, 
it's rather that the conclusions I make are always different.

 For example, you say that you don't like systray only for minimizing apps [2] 
(and I guess also [3], if one deciphers the "grok" sentence). So, for 
example, just plain minimizing of KNode to systray is wrong. However, KMail 
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?
- how about Licq, which shows status too, but only uses the icon for it, which 
is something the taskbar can do as well?
- 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)?

 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]. And I hope I was clear when I separated types of current systray icons 
to 1) those that have a window associated and 2) applet-like cases which have 
no window associated and the main window is the systray icon itself (ok, and 
also types 3) and 4) in my proposal which are irrelevant here). No wonder my 
patches designed to be for 1) don't quite fit your expectations when you try 
to bend them to be usable for 2). And 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.

 And your blog or the webpage actually don't answer this. It's generally about 
how the current spec sucks, because there are problems with modal dialogs, 
painting and finding out the status of the icon (a short paragraph in the 
spec I'd say, BTW), and how that should be fixed using some IPC. You say [10] 
you agree with the list of what's wrong with the current 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.

 So, to make this shorter, and to avoid me misunderstanding you once more 
again
- what you want and don't want in 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)?
- 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)?
And, some rather rhetorical ones, because I guess I know the answers, but just 
for completeness
- you're perfectly fine with having two completely different ways of 
implementing e.g. a CPU monitor for the panel?
- you don't mind the inability to rearrange some items on the panel as the 
user wants?

> > - systray icons that are much like normal panel applets, i.e. without
> > associated main window (cpu monitors, mail checkers, keyboard layout
> > switcher, etc.), should simply become real applets - Aaron's main gripes
> > about this, if I'm not mistaken, are "applets take too much space" and
> > "too difficult for the developer"
>
> yes, they take up more space

 Kicker problem

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

> ... 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 
(both presumably hidden behind some nice API)?

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

>
> it simply moves the problem of how to handle autoadding icons/applets, or
> how to encourage proper usage of this service, etc, etc, etc...
>
> if there was some actual tangible benefit to rearranging the problem that
> outweighed the space and developer time issues, i'd be all happy for it.
> but the fact is that rearranging the problem doesn't solve any of the
> issues inherent with this. and THAT is why i don't think it's worthwhile.
>
> > - systray icons that are kind of minimized apps that provide additional
> > information in the systray icon or are there simply not to occupy taskbar
> > space should be either added as small icons normally to taskbar or to a
> > separate applet that might actually pretty much resemble the current
>
> and it's precisely the "minimized app, not much else" icons that i find to
> be the greatest abusers of the systray.
>
> the systray is NOT another taskbar. or at least it shouldn't be. that's not
> the bloody point of it. it should be there as a way to provide quick access
> to information and interaction with services that are otherwise not
> possible. the systray does have a function in life in a proper desktop
> environment, and it isn't to minimize shit to. look at the current systray.
> the PROBLEM with it is we have a billion icons in it, MOST of which are
> simply "here's a quick way to access the main window".
>
> 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.

>
> >  Is there some session about Kicker/desktop/whatever scheduled for
> > aKademy?
>
> i've requested a BoF session there, yes.

 Great, count me in.

> > > a) we can do it right now. DCOP isn't good enough for this, and DBUS
> > > isn't really an option at the moment either. if/when DBUS gets into
> > > KDE4 then we can perhaps use that.
> >
> >  Unless you want to allow a single element to block everything, something
> > like DCOP or DBUS is not suitable because it cannot provide the state
> > without having to do a roundtrip asking for the information first.
>
> and you want the systray icons to become applets, which will almost
> certainly mean more dcop between the panel and the app, which will almost
> certainly mean the looming issue of blocking.
>
> but yes, having truly async calls would be a bare minimum requirement for
> the IPC used here.

 Thinking of it, DCOP would be actually fine if you only want another way of 
writing panel applets. Even the fd.o systray spec partially works by sending 
messages, and it probably could be done without any blocking involved, when 
the systray icon has to have explicit support and knows it has to talk to 
Kicker. Using an X window for communication or even X itself doesn't seem to 
be the best way here indeed.

 Which means my patches are probably not good for what you want. They, at 
least a part, should be good for improving the taskbar. Depends on how much 
you want the systray to duplicate the functionality of other parts of the 
panel.

> > > c) it still doesn't really answer needs like being able to easily query
> > > the app for information such as "what's your current status?" to get
> > > info for autohiding, etc. this is possibly solvable through inventive
> > > use of xatoms, but it's really going to be annoying
> >
> >  It does answer those needs, and it does it by use of xatoms that
> > actually doesn't need to be inventive at all. It's been working like this
> > for ages, how do you think the taskbar gets the window icon or window
> > caption? The only possibly annoying part I can see is me having to wrap
> > this for you into some nicer API than direct X.
>
> it means adding lots of new xatoms because the exact semantics we are
> looking for aren't covered. which means that the current capabilities do
> not cover our needs, which in turn means we need to come up with new
> solutions. so it's not like going the xatom route is a magic solution.

 Interesting how want to improve things yet you seem to find problems with the 
fact that what we currently have is insufficient and needs improving too.


[1]http://aseigo.bddf.ca/cms/1092
[2]http://lists.kde.org/?l=kde-core-devel&m=110840250507077&w=2
[3]http://lists.kde.org/?l=kde-core-devel&m=111727363126519&w=2
[4]http://lists.kde.org/?l=kde-core-devel&m=110834122219214&w=2
[5]http://lists.kde.org/?l=kde-core-devel&m=111358766213242&w=2
[6]http://lists.kde.org/?l=kde-core-devel&m=110841124008784&w=2
[7]http://lists.kde.org/?l=kde-core-devel&m=111358981200707&w=2
[8]http://lists.kde.org/?l=kde-core-devel&m=110837090706488&w=2
[9]http://lists.kde.org/?l=kde-core-devel&m=110841412418641&w=2
[10]http://lists.kde.org/?l=kde-core-devel&m=110841124008784&w=2

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


More information about the Panel-devel mailing list