On Sat, 29 May 2010 06:35:24 -
"John Emmas" wrote:
> When you call one of the g_idle_add() functions, you're saying to gtk,
> "don't execute this function now - but delay it until the GUI thread
> has some idle time available and execute it there." By doing that,
> you ensure that GUI element
Thanks a lot guys, I was naive beleiving GTK is absolutely thread-safe!
Tim.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
I'm sure that most new gtk programmers encounter this problem sooner or
leter. I know I did and my solution was essentially the same as Tadej's.
I wish I seen his blog though as it would have saved me a lot of time!
The key to success is to ensure that GUI elements only ever get modified
within
Hi.
> The gtk_progress_bar_set_fraction() is called by a separate thread.
This is probably the main cause of your troubles. Try reading this
blogpost for some info on how to use GTK+ from multiple threads:
http://tadeboro.blogspot.com/2009/06/multi-threaded-gtk-applications.html
(I'm sorry for th
Timofei Istomin wrote:
Hello,
I'm developing an embedded application using GTK+ (2.16.6) on the DirectFB
backend.
I use the gtk_progress_bar_set_fraction() to set the progress value, but it
doesn't affect the visible state of the widget until the touchscreen is
tapped.
Other GUI elements (butto
Hello,
I'm developing an embedded application using GTK+ (2.16.6) on the DirectFB
backend.
I use the gtk_progress_bar_set_fraction() to set the progress value, but it
doesn't affect the visible state of the widget until the touchscreen is
tapped.
Other GUI elements (buttons and text entries) are
