[vlc-devel] [vlc-commits] commit: skins2(Linux): check if _NET_WM_PID is supported (Erwan Tulou )
remi at remlab.net
Mon Jun 28 23:22:17 CEST 2010
On Mon, 28 Jun 2010 23:12:03 +0200, brezhoneg1 <brezhoneg1 at yahoo.fr> wrote:
> Do you mean that something's wrong or could be done in a better way
> in the patch ?
It looks wrong.
> Actually, window managers must advertise which EWMH features they
> support in _NET_SUPPORTED at the root window level.
That's irrelevant. You would care about _NET_SUPPORTED when you sent a
message to the window manager. Then you need to fallback to something else
if the feature is not implemented (e.g. full screen mode). You don't need
to care to set a property on your own window. If the window manager does
not support the property, it will ignore it. Most importantly, if the
window manager starts (or changes) after you check the NET_SUPPORTED
property, you won't accidentally "disable" a feature.
> For Ubuntu10.04, KDE4.4.2 does support _NET_WM_PID, but Gnome2.30
> The result for Gnome users was a series of the following non fatal
> (one per skins windows created):
> X Error: BadAtom (invalid Atom parameter) 5
> Major opcode: 18 (X_ChangeProperty)
> Resource id: 0x0
That means you sent a property change request which is not valid at the X11
protocol level. The property and/or the type atom probably did not exist.
Maybe the code does not intern the _NET_WM_PID atom correctly and forwards
an error value to the XChangeProperty function. That would happen if
"only_if_exists" is True when calling XInternAtom, whereas it should be
> The patch was just intended to remove these scary warnings by not
> setting the property, since the WM didn't care.
> Yet, what is the real use of _NET_WM_PID ? I don't know. (I guess
> it gives a means to kill a unresponsive process). It was implemented
> because the docky maintainers advised to do so. I'm wondering if third
> party software (Docky is not part of the WM) can make use of this
> feature even if it is not 'officially' supported by the underlying WM.
> In which case, it would be better to create this property anyway .... Is
> that what you suggested in your post ?
More information about the vlc-devel