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