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 [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
