Re: gdk/gtk+ win32 thread question, please help to explain
On Wed, Nov 23, 2011 at 12:43 PM, Michael Cronenworth wrote: > On 11/22/2011 10:13 PM, KC wrote: >> >> So the "Unfortunately ..." statement only apply to GDK on WIN32 ? >> It's safe to call GTK+ APIs (if protected by gdk_threads_enter/leave) >> from multi-threads even on WIN32 backend ? Is this correct ? > > No. GTK2 (I can't say about GTK3, but I bet it is the same) most definitely > does not work with threads even with gdk_threads_enter/leave under Win32. > > You can use threads in your app, but all GTK2 operations must be strictly > done by the primary thread. So, the gtk-thread.c example from http://developer.gnome.org/gdk/stable/gdk-Threads.html works on WIN32 is just good luck ? In that case, it will be better if the document can add a NOTE for gtk-thread.c example to remind reader it's not guarantee to work on WIN32. Regards, KC > ___ > gtk-app-devel-list mailing list > gtk-app-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list > ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gdk/gtk+ win32 thread question, please help to explain
On 11/22/2011 10:13 PM, KC wrote: So the "Unfortunately ..." statement only apply to GDK on WIN32 ? It's safe to call GTK+ APIs (if protected by gdk_threads_enter/leave) from multi-threads even on WIN32 backend ? Is this correct ? No. GTK2 (I can't say about GTK3, but I bet it is the same) most definitely does not work with threads even with gdk_threads_enter/leave under Win32. You can use threads in your app, but all GTK2 operations must be strictly done by the primary thread. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gdk/gtk+ win32 thread question, please help to explain
On Wed, Nov 23, 2011 at 11:06 AM, KC wrote: > Hi, > > According to http://developer.gnome.org/gdk/stable/gdk-Threads.html > > ... > Unfortunately the above holds with the X11 backend only. With the Win32 > backend, > GDK calls should not be attempted from multiple threads at all. > ... > > The "Unfortunately ..." statement does not mention GTK+, only GDK. > Does it only apply to GDK Win32 ? Or it applies to both GDK and GTK+ ? > > In my application, I call gtk_list_store_newv() from many non-main threads > (not via idle, timeout callback) and I do protect the GTK call with > gdk_threads_enter/leave(). It works fine even on Win32 !! > > Do I doing the right thing ? or just has good luck ? In fact, the example "gtk-thread.c" provide by http://developer.gnome.org/gdk/stable/gdk-Threads.html works fine on WIN32 too, and it calling GTK+ API from different threads (not from main-thread via idle callback) !! So the "Unfortunately ..." statement only apply to GDK on WIN32 ? It's safe to call GTK+ APIs (if protected by gdk_threads_enter/leave) from multi-threads even on WIN32 backend ? Is this correct ? Attachment is gtk-thread.c with a little modification (change pthread by GThread). Best Regards, KC > > Best Regards, > KC > ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
gdk/gtk+ win32 thread question, please help to explain
Hi, According to http://developer.gnome.org/gdk/stable/gdk-Threads.html ... Unfortunately the above holds with the X11 backend only. With the Win32 backend, GDK calls should not be attempted from multiple threads at all. ... The "Unfortunately ..." statement does not mention GTK+, only GDK. Does it only apply to GDK Win32 ? Or it applies to both GDK and GTK+ ? In my application, I call gtk_list_store_newv() from many non-main threads (not via idle, timeout callback) and I do protect the GTK call with gdk_threads_enter/leave(). It works fine even on Win32 !! Do I doing the right thing ? or just has good luck ? Best Regards, KC ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GtkAssistant : bug or feature ?
Hi all, When working with GtkAssistant, I used to find the widgets of the pages as children of the GtkAssistant by doing a recursive search starting from the GtkAssistant container. But, as of Gtk+ 3.2 (at least), I have found that GtkAssistant is now an empty container, and widgets are to be searched for as children of the pages. I think this behavior (or is it a bug ?) is less intuitive that the previous one: as widgets are described as children of the GtkAssistant in the GtkBuilder definition, it appears logical to me to search for these widgets inside of the GtkAssistant at runtime. And I did not find any reference to this in the developer manuals. Or is this a better, more "standard" way of getting a widget inside of a GtkAssistant ? Regards Pierre ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Updating css styles
Dear all, I'm trying to create a simple widget to display temperatures. I want something which is essentially a progress bar with a colour gradient going from green some of the way to red depending on what the temperature is. Since I like the way the standard Gtk progress bar does most things, I wanted to base my widget on that. Thus, the best way seemed to be to use css providers and the "-gtk-gradient" property (I give each widget a unique number and use this to set a different name for each widget, which allows me to set a different gradient for each widget). I've found when I want to update the gradient, if I just call the gtk_css_provider_load_from_data function on my css provider then nothing happens. Instead, I seem to have to remove my css provider from the style context, call load_from_data and then re-add it. I had a look in the docs but couldn't see any info about the correct way of doing this. Is this right, or is there a way I can notify my widget of the updated style? Also, while this method works nicely in most ways, it seems a like quite a lot of overhead having to create a different css class for each widget. Can anyone suggest a simpler way of achieving the same effect? Thanks, Tom ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
