Re: Wrong order when process some events

[Germán Arias]

Definitely this is wrong. After use some minutes apps like Ink, Gemas or
even Gworkspace the cursor stuck.

Germán.

On 2013-08-27 22:35:49 -0600 Germán Arias <address@hidden> wrote:

> 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
>> 
>> 
> 
> 
> 
> 
>