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: Wed, 28 Aug 2013 09:12:38 +0200

Thank you for testing this hack. I hope to have time to look into this tonight. 
It would be great to have detailed instructions on how to reproduce the new 
issues. I was hoping that the hack was at least as good as our previous code. 
Now I will have to write a clean solution :-(

Fred

On the road

Am 28.08.2013 um 07:04 schrieb Germán Arias <address@hidden>:

> 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
>>> 
>>> 
>> 
>> 
>> 
>> 
>> 
> 
> 
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnustep-dev



reply via email to

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