On 9/5/07, MenTaLguY <mental@...3...> wrote:
On Wed, 5 Sep 2007 03:12:19 -0300, "bulia byak" <buliabyak@...400...> wrote:
Well, I sort of patched it. Not a real fix because it's obviously a GTK bug.
Are you certain? It sounds like a feedback loop created by the event handler.
You're right that there was a feedback loop. I didn't notice it yesterday but now I fixed it. But this didn't fix the problem :) This IS a gtk bug.
Here's what happens. If you click and hold the arrow button to scroll the spinbutton, it enters autoscroll mode, in which it sends multiple value-changed events. An event causes writing to repr and document update, which is slow. While an event is processed, new value-changing events as well as setting the spinbutton value from within the program are both blocked, so there's no feedback loop in our code. Those value-changing events that arrive during our value-changed callback are indeed dropped, I checked that. But there's always at least one more event that comes AFTER the value-changed callback is finished and the widget is unblocked, and the callback runs again. And the biggest problem is that (probably because of that blocking?) the spinbutton loses the mouse-release event, and thus keeps autoscrolling forever (although it can be stopped by some other input events - clicking buttons etc.)