[Panel-devel] System tray

[Aaron J. Seigo]

On Tuesday 21 June 2005 01:55, Georges A.K. wrote:
> The first thing that should be discussed, IMO, is the technical
> aspect. 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. 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.

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.

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

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

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

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

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

-- 
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/panel-devel/attachments/20050623/f9045014/attachment.pgp