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 <p...@nervous-energy.org.uk> wrote: > >>>>> "CH" == Christoph Helma <he...@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. >
