systray specification...

[Carsten Haitzler (The Rasterman)]

On Thu, 2 Feb 2006 18:06:23 +0100 Lubos Lunak <l.lunak at suse.cz> babbled:

> On Thursday 02 February 2006 08:56, Carsten Haitzler wrote:
> > Ok - since the systray "spec" is still 0.x and a draft and still not
> > properly implemented in all places... I think I'd like to bring it up for
> > discussion. In starting to implement it... I've run across some nasty
> > issues. Let me bring up an image as it says 1000 words... :)
> >
> > http://www.rasterman.com/files/bad_tray.png
> >
> > Notice different icons have differing bacgkrounds? They are all solid
> > square blocks? Well if you know the spec, you know why... so... anyway.
> 
>  That's only a matter of (missing) XSetWindowBackgroundPixmap() with 
> ParentRelative. I guess the spec should say that.

tyhat ASSUMES the parent has a bg color/pixmap that is what would be
"underneath" the icon anyway. that is quite an assumption to make - especialyl
if the bg is dynamically drawn as needed etc. etc.

> > Several issues to bring up.
> >
> [handling of systray icons by systray itself]
> 
>  Actually we had this discussion in KDE some time ago with looong threads 
> (http://lists.kde.org/?l=kde-core-devel&m=110833557914964&w=2, 
> http://lists.kde.org/?l=kde-core-devel&m=110841124008784&w=2, 
> http://lists.kde.org/?l=kde-core-devel&m=111358766213242&w=2, 
> http://lists.kde.org/?l=kde-core-devel&m=111726975921264&w=2).
> 
>  I even implemented patches showing this, but I pushed them together with 
> claiming the fact that the systray UI itself is a mess and the discussion 
> eventually died out because of disagreements. But I guess our Kicker 
> developers could be interested in this.

cool- i see more XMBED haters :) i see things going to and fro for using an
non-x based mechanism - i do see the point, but then again, x is neutral and
does work. its a resource anythng that displays already shares. non-toolkit
clients can just use basic xlib and use it to advertise a systray icon. x
really is no more than a convenient existing ipc mechanism for this kind of
thing.it isnt a bifg departure from existing mechanism and existing code that
already works and thus barrirer fo entry is low.

maybe i'm pushing poop uphill - but i'd like to get traction on this and not
have it fizzle out. i want to hear what people have been thinking. most peolpe
i speak to on the wm/de and even app side of things have a loathing for the
existing spec to one degree or another. lets fix it to minimise the loathing.

ther eare many ways to skin a cat. lets skin this one a little better. :)

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com
裸好多
Tokyo, Japan (東京 日本)