On Mon, 2006-02-20 at 23:31 +0100, Mark Wielaard wrote: > Hi, > > The GtkScrollbarPeer wasn't setting the new value on the Scrollbar > component. And Component didn't handle translation of the > AdjustmentEvents to old style Events for use in handleEvent(). My test > application was using old style Events. It ignored the actual value in > the Event. And tried to use the Scrollbar.getValue() result to adjust > some properties. With this patch this all works now. > > 2006-02-20 Mark Wielaard <[EMAIL PROTECTED]> > > * java/awt/Component.java (translateEvent): Translate > AdjustmentEvents to 1.0 Events. > * gnu/java/awt/peer/gtk/GtkScrollbarPeer.java (changing): New field. > (setValues): Check whether we are currently changing and being called > back from the Scrollbar component. > (setBarValues): New native method. > (postAdjustmentEvent): Set new Scrollbar value. > * native/jni/gtk-peer/gnu_java_awt_peer_gtk_GtkScrollbarPeer.c > (Java_gnu_java_awt_peer_gtk_GtkScrollbarPeer_setValues): Renamed to > Java_gnu_java_awt_peer_gtk_GtkScrollbarPeer_setBarValue > * include/gnu_java_awt_peer_gtk_GtkScrollbarPeer.h: Regenerated. > > My main question is whether the "loopback" protection is correct. I got > the idea from GtkCheckboxPeer.
I think there is a deadlock risk with this patch and with GtkCheckboxPeer. postAdjustmentEvent is called with the GDK lock held and calls the synchronized method Scrollbar.setValues. Scrollbar.setValues calls GtkScrollbarPeer.setValues which acquires the GDK lock. So there's the potential for mutual embrace if a thread other than the GTK main thread calls Scrollbar.setValues at the right time. Why not just set the new value upon receiving the posted AdjustmentEvent in Scrollbar.processAdjustmentEvent rather than directly in GtkScrollbarPeer.postAdjustmentEvent? Tom
