Re: Should gtk_widget_draw be un-depreicated?
Thanks all. I'll just do the gtk_window_process_updates and that is that! Nicola Fontana wrote: Il giorno Fri, 04 Dec 2009 15:01:25 -0600 Harry Coin hc...@quietfountain.com ha scritto: The only answer I can think of to retain the ability to time most accurately, starting the moment that the image has been drawn is to use gtk_widget_draw right after setting the pixbuf. If gtk_widget_draw() is working for you, why don't you pasteadapt its code in your application? The implementation is quite trivial: http://git.gnome.org/cgit/gtk+/tree/gtk/gtkwidget.c#n3811 Ciao. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Should gtk_widget_draw be un-depreicated?
Presently the function gtk_widget_draw is deprecated in favor of gtk_widget_queue_draw. I need the great minds of gtk to think of a way I've missed to accomplish a certain task, or consider un-deprecating gtk_widget_draw. The context is a multi threaded application using gtk. In a thread that is not the main application thread that called gtk_init, a process waits to get the lock calling gtk_threads_enter. Then in a fairly tight loop at high thread priority it calls gtk_image_set_from_pixbuf to display an image, calls gtk_widget_draw, then starts a timer, waits for a process not related to the computer to send a response to the computer in reaction to the image, records a time for the reaction, then repeats the loop using different images. Timing is important and the images can change more than a few times per second. I've tried all sorts of non-deprecated combinations of gtk_widget_queue_draw, gtk_window_flush, gdk_flush, while(gtk_events_pending()) gtk_main_iteration(), etc. Doesn't work. The only answer I can think of to retain the ability to time most accurately, starting the moment that the image has been drawn is to use gtk_widget_draw right after setting the pixbuf. If there is a non-deprecated way to start a timer as soon as an image is known to be drawn without using gtk_widget_draw I'd need to be educated about it. If not I think there is a good argument to not deprecate gtk_widget_draw. Thanks one and all Harry Coin ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Display 1 buttons stuck after click until non-button used or other display gets focus
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
Re: Display 1 buttons stuck after click until non-button used or other display gets focus
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? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
