Re: Display 1 buttons stuck after click until non-button used or other display gets focus

[Harry Coin <hcoin quietfountain com>]

Harry Coin wrote:
> Hello!
>
> I've a mid-sized, debian/squeeze (2.18 gtk family) , amd64, 
> multithreaded, gstreamer (webcam in a small window), gdk ,  two 
> display gtkbuilder 2.0 application that worked well under debian/lenny 
> (stable).   Moving to 'squeeze' / testing a very weird effect 
> happens.  Display 1 is fullscreen, 0 is in a window. Display 1 has a 
> webcam image and a table of four rows, four columns that holds a 
> number of  on/off buttons and simple click buttons. 
> After the change from lenny, any of these buttons  will accept one 
> click, send the event signal to the right handler relative to the 
> click, the appropriate of the various handlerer returns after doing 
> the right thing -- but then gtk simply will not accept further clicks 
> (but allows normal mouse movement and will show the focus change on a 
> click attempt) until either:  a combo box on display 1 is changed, or 
> the mouse is moved even for a moment off display 1 onto 0, then back 
> on to 1 (without clicking anything on display 0).  After either of 
> those things, the toggle buttons will allow one more click, and the 
> cycle repeats.  \
>
> In all ways the application is normal after hours of use -- except 
> having to slide the mouse off display 1, on to 0, and back onto 1 
> before any further button (single or toggle) within the table on 
> display 1 (of 2) will accept a further click.  The application 
> responds normally in all other respects.
>
> How odd is that?  Any ideas?
>
>
>
>
> _______________________________________________
> gtk-app-devel-list mailing list
> gtk-app-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Update:  v2.18 When I compile the application that has two top level
windows to not move one of them to the other monitor, but instead leave
them both on the same monitor it all works normally-- whether launched
on monitor 0 or monitor 1.    Only when one of the two top level windows
is moved to another head/monitor will the button permit only one click
then all buttons are locked until the mouse moves off that screen
momentarily, or until a combo dropdown box on the 'button locked' screen
has content changed.   I'm thinking this is related to bug 597386
attempted to be fixed by Alex Larsson on 5 oct 09?