Re: Wrong order when process some events

[Fred Kiefer]

I think at least I understand now what is happening here. For me this
happens when I activate the colour panel by clicking on the text field.
That way the cursor for the text view seems to get set twice (or rather
three times), but gets popped once less. There is an additional problem
with text fields as the text view as we seem to get the events here in a
surprising order. I need to look into this for some more time.


On 28.08.2013 06:35, Germán Arias 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