gnustep-dev
[Top][All Lists]
Advanced

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

Re: Wrong order when process some events


From: Fred Kiefer
Subject: Re: Wrong order when process some events
Date: Mon, 26 Aug 2013 09:09:20 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8

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>




reply via email to

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