Re: Wrong order when process some events
On 29.08.2013 09:28, Fred Kiefer wrote: On 28.08.2013 21:51, Fred Kiefer wrote: On 28.08.2013 21:24, Eric Wasylishen wrote: Hi Fred, I found one I can consistently reproduce with the current gui: Open the memory panel (e.g. in Ink, open app info, click on app icon). Click on the memory window to focus it. Position the mouse over one of the table header dividers to get the horizontal resize cursor. Then, scroll very quickly for a second or two (the more scroll events you generate the more reliably this will work). When you move the mouse away the horizontal resize cursor should stick. Your explanation makes sense to me, I'm not sure why the hack is breaking. This is worse, the problem only happens with the new code, with the old one the cursor flickers a lot but in the end is correct. You don't even have to scroll very much one down and one up is enough for me. That should make it easier to analyse the issue. Splitting up the code really resolves the scrolling issue in the memory panel. But it definitely wont help for the colour panel and also this time I will do more testing before committing :-) I just committed my updated code. Please give it a try. I would have preferred to post the NSCursorUpdate events at the end of the queue, but for some reason that didn't work. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Wrong order when process some events
I think at least I understand now what is happening here. For me this happens when I activate the colour panel by clicking on the text field. That way the cursor for the text view seems to get set twice (or rather three times), but gets popped once less. There is an additional problem with text fields as the text view as we seem to get the events here in a surprising order. I need to look into this for some more time. On 28.08.2013 06:35, Germán Arias 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 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 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Wrong order when process some events
On 2013-08-30 05:26:12 -0600 Fred Kiefer fredkie...@gmx.de wrote: I think at least I understand now what is happening here. For me this happens when I activate the colour panel by clicking on the text field. That way the cursor for the text view seems to get set twice (or rather three times), but gets popped once less. I has noticed this. Sometimes this occurs because NSWindows update the cursor for a rectangle that has been discarded, as I explained previously. In other cases the cursor is updated when the rectangle get the focus (NSCursorUpdate) but also when the user move the mouse (NSMouseMoved). So this sets two i-beam cursors. There is an additional problem with text fields as the text view as we seem to get the events here in a surprising order. I need to look into this for some more time. Germán. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Wrong order when process some events
On 2013-08-30 05:19:19 -0600 Fred Kiefer fredkie...@gmx.de wrote: On 29.08.2013 09:28, Fred Kiefer wrote: On 28.08.2013 21:51, Fred Kiefer wrote: On 28.08.2013 21:24, Eric Wasylishen wrote: Hi Fred, I found one I can consistently reproduce with the current gui: Open the memory panel (e.g. in Ink, open app info, click on app icon). Click on the memory window to focus it. Position the mouse over one of the table header dividers to get the horizontal resize cursor. Then, scroll very quickly for a second or two (the more scroll events you generate the more reliably this will work). When you move the mouse away the horizontal resize cursor should stick. Your explanation makes sense to me, I'm not sure why the hack is breaking. This is worse, the problem only happens with the new code, with the old one the cursor flickers a lot but in the end is correct. You don't even have to scroll very much one down and one up is enough for me. That should make it easier to analyse the issue. Splitting up the code really resolves the scrolling issue in the memory panel. But it definitely wont help for the colour panel and also this time I will do more testing before committing :-) I just committed my updated code. Please give it a try. I would have preferred to post the NSCursorUpdate events at the end of the queue, but for some reason that didn't work. OK, now works. Thanks. Germán. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Wrong order when process some events
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 ger...@xelalug.org: 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 ger...@xelalug.org 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 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
Re: Wrong order when process some events
For the moment, the one problem that I can reproduce is this: On 2013-08-28 01:12:38 -0600 Fred Kiefer fredkie...@gmx.de wrote: On 2013-08-27 22:35:49 -0600 Germán Arias ger...@xelalug.org 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. Other problems are random. Or at least I can't reproduce these easily. Germán. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Wrong order when process some events
Hi Fred, I found one I can consistently reproduce with the current gui: Open the memory panel (e.g. in Ink, open app info, click on app icon). Click on the memory window to focus it. Position the mouse over one of the table header dividers to get the horizontal resize cursor. Then, scroll very quickly for a second or two (the more scroll events you generate the more reliably this will work). When you move the mouse away the horizontal resize cursor should stick. Your explanation makes sense to me, I'm not sure why the hack is breaking. Eric On 2013-08-28, at 1:09 PM, Germán Arias ger...@xelalug.org wrote: For the moment, the one problem that I can reproduce is this: On 2013-08-28 01:12:38 -0600 Fred Kiefer fredkie...@gmx.de wrote: On 2013-08-27 22:35:49 -0600 Germán Arias ger...@xelalug.org 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. Other problems are random. Or at least I can't reproduce these easily. Germán. ___ 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
Re: Wrong order when process some events
On 28.08.2013 06:35, Germán Arias 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. For the colour panel I get the same behaviour before and after my change. In both cases it is possible to stick with the I beam cursor, but you have to try hard to get this happening. This definitely is a problem that needs solving, but at least it is no regression. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Wrong order when process some events
On 28.08.2013 21:24, Eric Wasylishen wrote: Hi Fred, I found one I can consistently reproduce with the current gui: Open the memory panel (e.g. in Ink, open app info, click on app icon). Click on the memory window to focus it. Position the mouse over one of the table header dividers to get the horizontal resize cursor. Then, scroll very quickly for a second or two (the more scroll events you generate the more reliably this will work). When you move the mouse away the horizontal resize cursor should stick. Your explanation makes sense to me, I'm not sure why the hack is breaking. This is worse, the problem only happens with the new code, with the old one the cursor flickers a lot but in the end is correct. You don't even have to scroll very much one down and one up is enough for me. That should make it easier to analyse the issue. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Wrong order when process some events
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
Re: Wrong order when process some events
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
Re: Wrong order when process some events
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
Wrong order when process some events
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 WrongCursor-0.1.tar.gz Description: GNU Zip compressed data ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
