Re: Wrong order when process some events

[Germán Arias]

After more tests, I found problems with your hack. Open Ink and then
select Colors panel at menu and move the mouse (fast) over the textview,
this will stuck the cursor as an I-beam.

Germán.

On 2013-08-27 14:56:52 -0600 Fred Kiefer <address@hidden> wrote:

> As nobody replied I just committed my hack. On my machines it gives
> better results than the previous code. Please test whether this is true
> for you as well.
> 
> Fred
> 
> On 26.08.2013 09:09, Fred Kiefer wrote:
>> It may have seemed that there was no reaction to this mail but in truth
>> I have tried to understand the issue at least once in the previous
>> weeks. It just took me so long to come up with an idea. Last night I
>> finally found something promising. This was only possible with this
>> great example code that demonstrates the problem!
>> 
>> What I notices is that the method [NSWindow
>> _checkCursorRectangles:forEvent:] that converts mouse move events in to
>> NSCursorUpdate events goes through the list of views and detects both
>> exit and enter events. In most cases this will find either an exit or an
>> enter event, but sometimes the mouse moves directly from one tracking
>> rectangle to another. Now if there is an exit and an entered event, the
>> order in which they get detected is undefined. In that case it may
>> happen that we produce first an mouse entered event and then an exited
>> event. Which will basically leave the mouse cursor unchanged as we get a
>> push followed by a pop. I think that what we should get is first a pop
>> and then a push. Which means that we should go through the exit events
>> first and then detect the enter events. Within the exit events the order
>> isn't important, we just need the right count and within the enter
>> events the order should be outer to inner, which is guaranteed by our
>> code, as long as views don't overlap.
>> A simple way to see that this corrects the issue is to hack line 3644 of
>> NSWindow.m to post the enter event at the end of the queue. That way we
>> always get the exit events before the enter events and the later will
>> come in the correct order. This still is a hack, as we shouldn't post to
>> the different ends of the queue, this could mess around horribly with
>> what ever else is already in the event queue.
>> 
>> A proper solution could be to have a separate method to detect exit and
>> enter events. But this could be a lot slower than the current code. Or
>> we could send the exit events directly while posting the entered events
>> to the front of the queue. (In which case they would again be in the
>> wrong order the inner ones would come before the outer ones) Or we could
>> get all the NSCursorUpdate from the queue, sort them, exits first, and
>> process them in that order. But if there are two independent events the
>> overall sort would result in the incorrect order. (If we put the events
>> at the end of the queue)
>> 
>> Not sure, anybody with a better idea?
>> 
>> Fred
>> 
>> 
>> 
>> On 16.07.2013 08:18, Germán Arias wrote:
>>> I suppose that all of you (or almost all) has been facing a cursor problem
>>> with split views. When the split view contains a text view. Like in 
>>> ProjectCenter,
>>> where the browser and the editor are inside a split. Sometimes when you
>>> move the mouse from the browser to the editor the cursor remains as
>>> double arrow over the text view. This isn't a ProjectCenter problem.
>>> Attached a simple test with three views. Each one with a diffrent cursor.
>>> When you move the mouse from top to bottom, sometimes the cursor stuck.
>>> This problem depend of the movement velocity. And maybe if you have a
>>> fast computer, you will not see the problem. But at my computer this occurs
>>> frequently. The problem here is that, sometimes, the view under the mouse
>>> push its cursor, before that the previous view pop its cursor. The order 
>>> of
>>> these events is wrong.
>>> 
>>> I thought that this was because the NSWindow post the events at start of 
>>> the
>>> event queue. And if the event posted previously has not been executed. So,
>>> this would alter the expected order. But no, post the events at end is 
>>> worse.
>>> 
>>> Of course, a solution is increase the separation between views (or cursor
>>> rects). But in splitview this is not possible. Any idea?
>>> 
>>> Germán.
>>> 
>>> <WrongCursor-0.1.tar.gz>
> 
> 
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnustep-dev
> 
>