Thoughts on the systray II.

[Lubos Lunak]

 Hello,

 this is more or less a followup to 
http://lists.kde.org/?l=kde-core-devel&m=110841124008784&w=2 , which died out 
(because of a certain person being a bit busy, I guess :-/ ). I'd like to 
revive and continue with it, and present also some "show me the code".

 To quickly summarize (see the link above for full details), the things I 
suggested were:
1) not using systray for apps minimizing, using another taskbar instead, which 
may in the end even look a lot like a systray from the user's point of view. 
As you'll see below this in practice mainly means replacing KSystemTray and 
the underlying protocol. People in general seemed(?) to like this part, so 
see below about the code.
2) converting applet-like systray apps to real applets. Aaron had some issues 
with this because of having bad nightmares about XEmbed, so this needs more 
discussion, the remaining complains can be basically solved by saying "so 
that needs fixing/improving" if my memory serves me well.
3) improving KNotify so that apps that now use systray just to notify about 
things will stop using systray, will stop rolling their own notification 
implementations, and will simply use KNotify. This seemed to be generally 
like as well.
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.

 Ok, now the more interesting part, i.e. the one with patches. See attachments 
with patches for kdelibs/kdecore, kdebase/kicker/applets/systemtray and 
kdebase/kwin . They kind of implement 1), it still needs quite some work and 
they're a bit hackish in some places, but it's good enough for seeing the 
idea in practice. Note that you need current CVS of kdecore for them to work 
properly.

 With the patches now KWin has a new titlebar button which controls whether a 
window should be trayed or not. In order to save me some work the patch 
actually now uses the button for keeping a window below others, you need to 
enable it in the decoration config if you don't see it. Systemtray is patched 
to also provide an icon for such windows. Window have two new flags, 
NET::Trayed and NET::TrayedHidden, first one meaning the window should show 
in the systray, the second meaning it's in the systray and hidden. I.e. 
nothing is set, it's a normal window, only Trayed is set, the window is 
visible, it has an icon in the systray and it has also a taskbar entry, both 
flags are set, it's hidden in the systray and has no taskbar entry. Works for 
any application, blah blah (see the URL above for all the benefits).

 It still needs doing something with the KSystemTray class. First of all 
there's something like this class needed to show the RMB menu, probably some 
KNewTray class that will provide the tray the menu and all the other things 
it might need from the app. And secondly, KSystemTray and the attached 
patches clash in quite ugly ways, so having this in 3.5 would be ... 
interesting from the user's point of view. Basically, the apps again roll too 
many things on their own, so they e.g. block quiting when one closes the main 
window, which means that if KSystemTray functionality is mapped to this new 
functionality, the app may end up running in the background, if KSystemTray 
is left as it is, such apps may have two systray icons. Not that the 
remapping of the KSystemTray functionality would be that trivial without 
dumping it completely and starting anew.

 Anyway, if people will like this, the plan would be something like
- finishing the patches, so that there really is a separate titlebar button, 
that there would be the RMB menu, and who knows what
- deciding on the exact GUI behaviour (which can be enforced to be consistent 
between the apps), e.g. I think the titlebar button should perhaps just put 
the icon into the tray for LMB and additionally also "minimize" the window 
for RMB. Currently one has to toggle the KeepBelow button and then minimize. 
This also includes deciding whether the icons should be in a separate systray 
applet, or should be perhaps in a separate part of the taskbar, or so.
- proving a KSystemTray-like class that'd provide the RMB menu, and perhaps 
icon, tooltip or whatever.
- (the "I'm bored case") making it work somewhat reasonably even for 3.5 
without having two systray icons and so on

 Ok. Comments, flames, threats, cookies, and similar stuff related to this?

 Now going to reply to Aaron's mail[*]. (The "XEMBED" case, AKA "beat Aaron 
until he likes my idea" ;)  ).

[*] http://lists.kde.org/?l=kde-core-devel&m=110841412418641&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/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kdecore.patch
Type: text/x-diff
Size: 24930 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050415/aadc4ddb/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kwin.patch
Type: text/x-diff
Size: 12482 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050415/aadc4ddb/attachment-0001.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: systemtray.patch
Type: text/x-diff
Size: 17011 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050415/aadc4ddb/attachment-0002.patch>