Changing the last argument of XInternAtom to False works too. Up to now
I did not run into troubles with WM_HINTS, but I might have just been
lucky.
Christoph
Atom wmProperty = XInternAtom(display->get(), "_MOTIF_WM_HINTS", False);
On Thu, 27 Oct 2011 00:05:26 +0100, pod <pod_AT_nervous-energy.org.uk> wrote:
> >>>>> "CH" == Christoph Helma <helma_AT_in-silico.ch> writes:
>
> CH> Thanks! Changing that line to
>
> CH> Atom wmProperty = XInternAtom(display->get(), "WM_HINTS", True);
>
> CH> seems to solve the problem.
>
> ... and almost certainly introduces an entirely different sort of
> problem.
>
> I don't think WM_HINTS and _MOTIF_WM_HINTS are at all the same thing.
>
> What you have done merely appears to work because WM_HINTS almost
> certainly already exists in the server, thus XInternAtom(..., True) is
> pretty much certain to return XA_WM_HINTS (35, the predefined atom
> number for WM_HINTS) and not None.
>
> However, the value of a WM_HINTS property is intended to have a specific
> structure that is certainly not the same structure as the Hints struct
> value that is now being set in the subsequent XChangeProperty() call.
>
> As Anselm hinted probably what you ought to do is change the last
> argument in that call to XInternAtom() from True to False. That ought
> to mean that if the _MOTIF_WM_HINTS atom does not already exist in the
> server then it is created and an atom number (and not the value None) is
> returned for it. This atom number should then be valid for use in the
> subsequent XChangeProperty(). I'm afraid I can't comment on whether the
> structure value as given by the Hints struct is in fact appropriate for
> a _MOTIF_WM_HINTS property.
>
> By leaving that last argument as True and not checking wmProperty==None
> after the XInternAtom() call you in fact still have precisely the same
> bug. It is just now much less likely (maybe even impossible, when
> talking to a normally functioning X server) to occur.
>
Received on Fri Oct 28 2011 - 14:16:02 CEST