Thank you for testing this hack. I hope to have time to look into this tonight. It would be great to have detailed instructions on how to reproduce the new issues. I was hoping that the hack was at least as good as our previous code. Now I will have to write a clean solution :-(
Fred On the road Am 28.08.2013 um 07:04 schrieb Germán Arias <[email protected]>: > 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 _______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
