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