gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Last cursor issue (I hope)


From: Fred Kiefer
Subject: Re: Last cursor issue (I hope)
Date: Sun, 15 Sep 2013 23:43:14 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8

On 14.09.2013 09:01, Germán Arias wrote:
> I only can reproduce this problem with in-window menu. So, here
> the steps to reproduce this problem:
> 
> 1) Set NSWindow95InterfaceStyle for Ink.
> 2) Launch Ink and moves the mouse where the TextView will be
>     displayed (before it appears on the screen).
> 3) Move the mouse out of textview, the I-beam is stuck.
> 
> This occurs because NSEvent objects, retain the GSTrackingRect
> objects. So sometimes, when NSWindow needs update the cursor,
> the GSTrackingRect provided by the NSEvent object has been
> discarded. So NSWindow update the cursor to a rectangle that there
> isn't present at window.
> 
> The most easy solution I found for this problem, is check the retain
> count of the GSTrackingRect object. If this value is higher than one,
> mean this rectangle exist somewhere and not only at NSEvent object.
> Googling, many people don't recommend the use of method
> -retainCount. But I tested this and works for me. This is the hack that
> I added at line 4061 in NWindow.m:
> 
> if ([r retainCount] > 1)
>   {
>     [c mouseEntered: theEvent];
>   }
> 
> What you think about this?

As you already know, checking the retain count is almost always the
wrong thing to do. The most likely reason for the problem here is that
the cursor rectangle has already been invalidated when the
NSCursorUpdate event arrives. I would expect that checking the isValid
Method on that rectangle should resolve this. But I would also like to
understand which other event is it that gets processed between the mouse
move and the NSCursorUpdate?

Fred




reply via email to

[Prev in Thread] Current Thread [Next in Thread]