Thoughts on the systray II.

[Lubos Lunak]

On Friday 15 of April 2005 20:29, Aaron Seigo wrote:
> On April 15, 2005 16:46, Lubos Lunak wrote:
> > 2) converting applet-like systray apps to real applets. Aaron had some
> > issues with this because of having bad nightmares about XEmbed, so this
>
> no, not because of XEmbed, but because the systray form factor and
> ease-of-programming have real world benefits that applets will not be able
> to cover as well.

 Really? What exactly should be the difference? With a systray app is roughly 
like this, if I'm mistaken:
- get some template app with the Makefile.am and the stub with main()
- use KSystemTray to provide the necessary info and the contents of the 
systray icon
- make install
- add the systray icon by finding it in the K-Menu

 I'm talking about applet-like systray icons now of course, the ones like 
kxkb, docked cpu/network/whatever indicators and so on, not things like 
KMail's or KArm's systray icon.

 Now, what's should be the big difference compared to something like:
- get some template with the Makefile.am
- use KPanelApplet or KSimplePanelApplet to provide the necessary info 
(roughly the same info like above I'd say) and the contents of the applet
- make install
- add the applet by finding in the the kicker RMB menu

 In fact in some cases that could be even simpler. E.g. my favourite Klipper 
quit dialog again - you don't need anything like that with applets. Do you 
want a new kicker applet? Just add it with the menu. Don't you want the 
applet anymore? Remove it and be done. Do you want a systray icon? Run the 
app. Don't you want it anymore? Remove it. Doesn't work? Well, perhaps you 
need to confirm that you really want to get rid of it completely and that you 
haven't got just momentarily bored by it. Or perhaps you need to find some 
checkbox. Or maybe something else, who knows?

 There may be things that might need some work this way. E.g. Kicker should 
allow applets not to take the full panel height and two of them have the same 
X coordinate. I intentionally say X coordinate because I think there's no 
need to implement a grid. Just if two applets have the same X and fit 
together within the height, put the first one above the second one.

 
 But I think you still fail to realize what I really want. My problem is that 
the current systray as a whole sucks big time. Yeah, the underlying mechanism 
isn't that good either. But the real problem with the systray is that it's 
just a random inconsistent mess of everything. There are applets. It's used 
for notifications and status reporting. It's used for removing rarely used 
things from the taskbar. It's used for quick access. People don't know how to 
put some things there (sorry, ksystraycmd is just a hack). People get annoyed 
by the "really quit? ... er ... like forever?" dialogs. People get confused 
by the minimize vs close buttons functionality.

 Why should I have a keyboard layout indicator next to some icon representing 
a window I'm not going to touch for the next hour and some icon that will 
blink when something important happens? I think that if we just split the 
systray into separate parts for such separate uses that would be already an 
improvement.

 That's why I want to have applet-like systray icons converted to real 
applets. Because, face it, applet-like systray icons are just like real 
applets from the UI point of view, it's just the underlying implementation 
that's different. This may cause some problems in Kicker like having too much 
space taken by the applet handles, but I think those are rather problems of 
Kicker than applets.

> > 4) not using the systray for daemons, quick access and such stuff,
> > instead simply not having any GUI for those, or using applets/whatever.
> > I'm not actually sure what was the opinion on this.
>
> depends on the daemon. for some this is the obvious step (e.g. the
> uiserver), for others it may not be. i don't think we can classify them all
> together unfortunately.

 But we can try. Do you have any examples that'd be different from George's 
KWallet and print manager case?


On Friday 15 of April 2005 23:29, Aaron Seigo wrote:
> On April 15, 2005 16:46, Lubos Lunak wrote:
> > flags, NET::Trayed and NET::TrayedHidden, first one meaning the window
>
> thinking about this a bit more, i'm ok with using WM hints for now .... but
> i'd like to see this move away from being X specific so that it runs as
> expected elsewhere too and is therefore futureproofed. of course, that
> means having an IPC mechanism that doesn't require an explicit target but
> allows the consumer to poll for information as WM hints do.

 It is not X-specific, strictly speaking. Why should you care how 
KWinModule::trayedWindows() gets the list? I don't think something like DCOP 
could work here because that way one stuck app could freeze everything that'd 
want to find out some detail. WMs don't ask apps about details, but apps 
always set the info and the WM can fetch it anytime it wants. Also, since the 
patches move major portion of the functionality to KWin, it simply has to be 
X. I have no idea how other platforms handle that.

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