Weird wm behavior with xeyes

Jeremy Huddleston jeremyhu at
Fri Nov 28 01:14:48 PST 2008

I traced the problem to wrong coordinates in a XShapeCombineShape...  
code refactoring missed one obscure corner case... sigh...

All better now...

On Nov 27, 2008, at 23:06, Jeremy Huddleston wrote:

> On Nov 27, 2008, at 21:57, George Peter Staplin wrote:
>> That sounds odd.  I ran into a bug like that in Whim with skype.  It
>> turned out to be that the offsets in Whim weren't taking into
>> account the titlebar size in some cases, so the sent event didn't
>> match where the application's window really was.  Borders can also
>> cause that in some cases.
> It's not actually the time that determines if the eye mask is in the
> right place, it's the initial placement of the window... it's as if
> its placing the mask at a location in the window using root-relative
> coordinates when it should be using window-relative coordinates...
> I am stumped... gonna look at all the x-protocall calls in quartz-wm/ 
> x-
> window.m and do some debug spew on them and compare to the same spew
> in the old working version... hopefully that'll reveal the problem...
> I tried looking in xeyes to see how it treats the two layers
> differently, and it looks like it treats them exactly the same... =/
>> Another bug I ran into that is somewhat like that had to do with
>> windows jumping when they were initially resized.  That was caused
>> by resize increments/hints.  I learned that you have to apply the
>> hints, then resize the window, and update the state carefully.  Thus
>> the code looks something like this:
> Yeah, it's not happening on resize though...
>> On Nov 27, 2008, at 13:51, Jeremy Huddleston wrote:
>>> Someone discovered an odd bug that our wm exhibits with xeyes.  The
>>> "black-lines" are drawn at the right spot, but the ovals that select
>>> which region to view move down as quartz-wm starts and stops.
>>> ConfigureNotify is always returning the upper left of the "inner"
>>> window, and we are doing the correct reparenting offset...  anyone
>>> seen something like this before of have some guesses for me to
>>> persue?
>>> I put together an animation of this happening here:
>>> If you don't like .mov, you can see the individual frames:
>>> Thanks,
>>> Jeremy
>>> _______________________________________________
>>> xorg mailing list
>>> xorg at
> _______________________________________________
> xorg mailing list
> xorg at

More information about the xorg mailing list