Hi Fred, Thanks, this solve the problem. I still have the problem in GNUMail, but I can't reproduce this with a simple app test. So, could be a problem in GNUMail.
There are the other problem I reported you previously, that occurs when NSWindow update a cursor for a cursor rectangle that has been discarded. And I discovered another problem related with cursor, but I will try to make a test app, so you can test it. Germán. On 2013-08-27 14:56:52 -0600 Fred Kiefer <fredkie...@gmx.de> 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 > Gnustep-dev@gnu.org > https://lists.gnu.org/mailman/listinfo/gnustep-dev > > _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev