Le 08.07.2012 12:49, Uli Schlachter a écrit :
My understanding is that if I set _NET_SYSTEM_TRAY_COLORS property
to
white, I will get the appropriate effect. With the help of gdb and
three
hours later, I came with the following thingy to get what I want:
xprop -id 0xc00002 -format _NET_SYSTEM_TRAY_COLORS 32c -set
_NET_SYSTEM_TRAY_COLORS
65535,65535,65535,65535,8670,8670,65535,32385,0,8670,65535,8670
Quite a simple format, he?
Yep! The first RGB values are for the foreground color, the next ones
for error color, the next ones for warning color and the last ones for
success color. Just for people who Google may redirect here.
Then, I restart my applet and, bingo, I get the appropriate color. I
don't understand why I should restart the applet while GTK has code
to
detect a change to this atom but this is not very important.
Sounds like a bug in GTK+.
OK, I have filed a bug for this. I'll see what they say:
https://bugzilla.gnome.org/show_bug.cgi?id=679592
Now my questions:
0xc00001 is awesome.
Why is window 0xc00001 awesome? If you want me to guess, it's the "I
am still
alive"-window which awesome has to create for the
_NET_SUPPORTING_WM_CHECK
property of the root window.
Yes, that is.
I suppose 0xc00002 is related.
If you want me to guess again: That's awesome's systray window. All
systray
widgets get reparented into that and its used for displaying the
systray.
Yep.
How could I compute it?
In a sane way? You don't.
Reading Freedesktop specification, it seems the right way is to use
XGetSelectionOwner (or the XCB equivalent). I suppose this is not
possible from Lua.
In an insane way? "prop -root _NET_SUPPORTING_WM_CHECK" and then add
one, but
this just happens to work accidentally since these two windows are
(in order)
the first things that awesome creates. There are no guarantees for
this.
In the meantime, I have also discovered that awesome is setting
_NET_SYSTEM_TRAY_ORIENTATION (which is part of the system tray
protocol). Therefore, I can search for a window with this atom set and
add mine.
[...]
Second question: is there something cleaner than to call xprop to
modify this property?
I can't find any spec for this stuff and I don't really want to add
support for
this just from some random commits.
Sounds reasonable. I have filed a bug about this (against GTK):
https://bugzilla.gnome.org/show_bug.cgi?id=679591
Dunno if someone will care for such a thing.
--
To unsubscribe, send mail to [email protected].
