Weird wm behavior with xeyes

Jeremy Huddleston jeremyhu at freedesktop.org
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:
>>>
>>> http://people.freedesktop.org/~jeremyhu/xeyesbug/xeyes.mov
>>>
>>> If you don't like .mov, you can see the individual frames:
>>> http://people.freedesktop.org/~jeremyhu/xeyesbug
>>>
>>> Thanks,
>>> Jeremy
>>>
>>> _______________________________________________
>>> xorg mailing list
>>> xorg at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/xorg
>>
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg




More information about the xorg mailing list