thoughts on the systray

[Aaron J. Seigo]

On Monday 14 February 2005 01:00, Lubos Lunak wrote:
>  A random list of things that are wrong with the systray:

i would generally agree with this list. =)

>  Aaron's proposal clearly aims to fix some of these, but it might be
> simpler to dump the systray idea altogether and start from scratch (which
> doesn't exclude the possibility the result will resemble the original at
> least somewhat).

well, i think you're describing exactly what i'm suggesting. screw the current 
systray, redefine it as an IPC driven concept and kick the offenders to the 
curb.. er, the taskbar.

>  The systray is currently used for the following things, at least the ones
> I can think of:
>
>
> 1) minimalization
>   - e.g. kscd, amarok, ksirc and similar - The basic intent is apparently
> to save space from the taskbar.

no. they are there to provide a place to easily access common actions in an 
omnipresent way without taking gobs of screen space. e.g. "Play" and "Stop"

>  - Suggested fix: Stop using the systray for this, and improve the taskbar.
> It shouldn't be a big deal to improve it so that certain taskbar entries
> can be shrunk only to the icon and moved to the right.

i agree with this. i even stole this idea of yours and mentioned it earlier in 
this very thread =)

>   - Aaron wouldn't have to bother with his spec for this.

in fact, i certainly don't plan on doing so =)

> - One more thing missing to be a good replacement for the current systray
> way of doing this is the context menu, e.g. the play/stop/next etc. entries
> for kscd/amarok. The idea is the application would simply associate the
> actions with its main window, and the taskbar would provide these actions
> in the popup.

this requires the taskbar always being there, and falls apart rapidly when we 
deal with applications with multiple windows or that wish to do something 
more interesting than offer a popup, as kontact likely will.

> Since this is out-of-process, it's not possible to simply 
> provide a QPopupMenu and give it to the taskbar (Aaron's proposal can't do
> this either as far as I can say).

i played for a while with an XMLUI-ish solution, but eventually settled on the 
concept of simply saying "pop whatever you (the app) consider your contextual 
UI at point (x, y)"


> - Suggested fix: Stop using the systray for it, convert them to applets.

*cough*relocating the problem rather than fixing it*cough*

a knotes applet, which has already been discussed in this thread, would also 
suck heavily. this is not a universal hammer.

> Another part is creating a spec that'd be shared with GNOME. The small
> problem here is Aaron would have to be treated for his allergy to the X
> character ;), like in the word XEmbed.

that's like saying that a child has an allergy to hot stove elements because 
they touched one once ;)

>  But I fail to see how using e.g. 
> Python scripts instead can be considered simpler.

did i ever say simpler? no. i said better, as in "won't hamstring kicker" and 
"won't make our users wonder why Open Source desktops are such crap"

> In fact I'd support 
> Havoc's opinion that many of the alleged XEmbed problems are caused by
> incorrect usage of bugs (XEmbed is not exactly trivial after all). For
> example, while I haven't tried it for real, after consulting some X11 docs
> I don't a reason why fake transparency should be impossible with XEmbed.

*sigh* i could give a flying you-know-what about transparency. i've mostly 
licked that with the system tray. it's horribly inefficient, but it works. 
composite will likely address a lot of that inefficiency. 

the issue is with functionality. allowing the panel and the applet to talk 
with each other and work closely with each other. think KParts and how they 
leverage XMLGUI.

i'm really dissapointed that i list all these _functionality_ issues and yet 
you and some others keep picking on the more trivial painting issues. i dare 
you to step up to the plate and consider the HARD problems i've put forward, 
not the EASY ones that make it easy to make your argument stick together.

> - One additional problem here is that the content of the applet window is
> completely controlled by the applet. This is definitely necessary for some
> applets, e.g. for the kmix applet (applet, not the systray kmix). But for
> many the functionality along the lines of 'show this pixmap' and 'show
> context menu', like in Aaron's proposal, is enough. I think this could be
> simply handled by subclassing KPixmapPanelApplet from KPanelApplet, which
> would solve Aaron's objections to applets.

this isn't my objection to applets.

> 3) Notification

i totally agree with everything you say here in point 3.

> 4) Daemons, quick access, whatever
> - This is stuff like alarmd (or whatever that systray icon KOrganizer
> brings all the time is called), the several systray icons from SUSE
> (susewatcher, suseplugger, profile switcher), and maybe even Klipper.

kalarmd, klipper, yes. i don't think this a universal truth however. kalarmd, 
kmail and akregator's systray icon should all be amalgated into one entity, 
really. this is made easier using IPC, actually =)

> - Suggested fix: Stop using the systray for this. This stuff should be
> invisible daemons, controlled by let's say their kcm modules. If there's
> need for some visual representation, there can be an associated simple
> kicker applet, which will using DCOP talk to the daemon. The same way there
> can be applets for the quick access, so that people not wanting such waste
> of space can still have the functionality, while those who want this simply
> add the applet.

no. making people add applets is not something we can rationally expect. think 
about locked down configurations and new/simpler users. moreover, saying 
"Make it an applet, talk via DCOP/DBUS" is no different than saying "make it 
a systray icon, talk via DCOP/DBUS". it doesn't address an issue, it moves it 
to the main panel. and unless we wish to duplicate all the problems currently 
contained in the small area of the systray to the larger space of the panel 
itself, we shouldn't go down that road.

>  The nice thing about this proposal is that 1), which bothers me the most,
> requires only forking the taskbar applet or writing a new one, which I
> intend to do unless somebody persuades me this whole thing is a bad idea,
> so I can go for it and try at least 1) for real even if you don't like it.

by "fork" i hope you mean "make a branch in CVS, where i'll try and coordinate 
with the maintainer". i swear, if you create TaskbarV3 and make my life 
merging all these independently created, positive improvements any harder, i 
will hunt you down, say "nazdar!" and beat you silly. well, i won't say 
nazdar. but the rest... oooooooh. ;)

>  So, comments, flames, angry screams :) ? This is still no proper flamewar
> so far, I hope this helps you to try harder ;).

hahaha.. ok. hrm. let's see. your mom smells bad. and kwin's crap. 
now, which one of those sentences got you more upset, Seli? ;)

-- 
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/kde-core-devel/attachments/20050214/40a26b8e/attachment.sig>