[Panel-devel] System tray

[Lubos Lunak]

On Thursday 23 of June 2005 07:43, Aaron J. Seigo wrote:
> On Tuesday 21 June 2005 01:55, Georges A.K. wrote:
> > The first thing that should be discussed, IMO, is the technical
> > aspect.

 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. In short, if I finally got it right, Aaron's idea on the systray 
UI itself is something like "the UI concept itself is fine, just the 
implementation sucks", while I rather think like "the UI concept is pretty 
broken, and while some parts of the implementation are fine, it doesn't make 
sense to discuss them as long as the concept itself is broken".

 My patches don't quite technically match Aaron's expectations, because our 
visions don't quite match either. My ideas, in short (see 
http://lists.kde.org/?l=kde-core-devel&m=110841124008784&w=2 for full list), 
is:
- the systray as it is now should be dumped, only perhaps kept for backwards 
compatibility
- 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"
- 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 systray 
(but with only one specific purpose). Since this is what my patches implement 
it doesn't quite fit the requirements of the other abus^H^H^H^Huses of the 
systray.

 Is there some session about Kicker/desktop/whatever scheduled for aKademy? I 
think it'd be perhaps the best if we simply gathered in a room there and 
spent some time in front of a blackboard arguing about things like this.

> > Should the QXEmbed be retained or should we switch to an IPC 
> > mechanism ? I would favour the second option for several reasons.
>
> yes, XEmbed is being kicked to curb, except as a means to keep backwards
> compat.

 And interoperatibility. That's probably not doable without XEMBED.

> the real question at the moment is if we use WM hints or true IPC.  
> the implementation Lubos has been working on uses WM hints. the benefits to
> this approach are:
>
> 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.

>
> b) there's code written already ;)
>
> c) it allows any X11 app to use it
>
> the disadvantages are:
>
> a) it's tied to X11. would be nice to allow non-X apps to easily use this
> new service.

 Maybe nice, but not necessary. Currently anything you see on the screen is 
tied to X11, because, well, it's X11 handling it all.

> b) it requires a window to map the wm hints to

 See above the part about visions not quite matching.

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

>
> d) it ties us to an iconic representation of the systray. i'm really not
> into the tight coupling of model and view that the systray currently has
> and i think this is one palce that a separation between M and V is very,
> very good

 I don't think so, just like the taskbar doesn't have to be a list of icons, 
but it can be e.g. Kasbar or Kompose. But then I'm afraid I fail to see what 
you actually wanted to say here.

>
> > dcopidl). For programs that need a static tray (no modification to the
> > icon or popup menu), all they would need to do is describe it (XML)
> > and connect the slots to signals.
>
> i don't think we want to go down the route of creating menus with XML. i
> originally had that as part of my ideas as well, but then eventually
> discarded it as i thought more about it. if we can ensure simple menus it's
> easy enough, but handling possible DnD, custom menu items, updates to the
> menu (e.g. item active -> inactive while the menu is popped up) ... it all
> becomes a bit tedious. easier IMHO is to just pass a "pop up your menu at
> this point on screen" message and let the app handle it all. this is what
> has been done in Lubos' code.

 Sadly, this "pop your menu here" seems to be the only feasible way.

>
> > The obvious problem with that is
> > interoperability with other DE and with existing non-KDE apps (aMsn
> > for example).
>
> this is true no matter what we do. we'll keep support for the current
> mechanism around for compat reasons, but we should also pursue a spec on
> FD.o once we are content with the way it's working in KDE. whether or not
> others pick it up is another matter, but up to them. there is only so much
> we can do and we really do need to keep KDE first in mind when it comes to
> making things that Don't Suck(tm).

 Agreed. We first need to get it right.

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