Re: Does gtk have issues with STL?
On Mon, 2008-02-11 at 17:08 -0700, Michael L Torrie wrote:
> Paul Davis wrote:
> > EITHER make GTK/GDK/X11 calls from a single thread only OR
> > use GDK_THREADS_{ENTER,LEAVE} around every (group of) GTK/GDK/X11
> > call(s).
>
> This seems to crop up all the time. From what I recall, the use of
> threads of any kind with GTK on Win32 is not supported,
win32 is sort of thread-safe but all events for a given window must be
handled by the thread that created the window. its an odd system if you
come from X11. this is true whether you use GTK or "native" win32 APIs.
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Row with different columns at runtime?
Hi, I am using GTKmm for a little project. I have a problem because I do not know how to solve the following problem: I have a List Store. In the most right column shall EITHER be a text, OR be a combo box, OR be a button etc. My programme shall read a file which shall tell it which type (text, combo, button etc.) to use for this column in the current row. However, I do not know how I can realize such a dynamic row. Is there a solution? Greetings, Johannes -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Does gtk have issues with STL?
Paul Davis wrote:
> EITHER make GTK/GDK/X11 calls from a single thread only OR
> use GDK_THREADS_{ENTER,LEAVE} around every (group of) GTK/GDK/X11
> call(s).
This seems to crop up all the time. From what I recall, the use of
threads of any kind with GTK on Win32 is not supported, even with the
ENTER/LEAVE calls around every GTK/GDK call. The only way to use
threads and GTK in win32 is to do the g_idle_add thing to trigger a
callback from the thread.
Usually trying to use threads in GTK in win32 doesn't cause memory
corruption, though, so that's a separate problem, I think.
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Does gtk have issues with STL?
On Mon, 11 Feb 2008, Paul Davis <[EMAIL PROTECTED]> wrote : > >the use of threads in GUI toolkits that originated in the X Window world >is generally quite difference than the use of it with GUI toolkits that >originated in the win32 world. Actually I never noticed the difference, because my exposure to Win32 was through Borland's VCL library, which is non-thread-safe in similar ways to GTK. The "all GUI calls in one thread" rule applied there too. But being more accustomed to embedded code for systems with no OS and only a minimal scheduler, I don't tend to use threads anyway. -- Rob Pearce http://www.bdt-home.demon.co.uk The contents of this | Windows NT crashed. message are purely | I am the Blue Screen of Death. my opinion. Don't| No one hears your screams. believe a word. | ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Does gtk have issues with STL?
On February 11, 2008 05:37:54 pm Vallone, Anthony wrote: > From: > "Vallone, Anthony" <[EMAIL PROTECTED]> > To: > gtk-list@gnome.org > Myself, I avoid the enter/leave calls in favor of g_idle_add() as a > mechanism to queue all gui calls for the main event loop thread. Let > your other threads stick to performing the non-gui work, and you'll save > yourself from many headaches. (I wish someone told me that 3 years ago). Hi, I'm interested to know more about that. Is there some source code example that I can follow? -- JP ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
GLib 2.15.5
GLib 2.15.5 is now available for download at: http://ftp.gnome.org/pub/GNOME/sources/glib/2.15/ glib-2.15.5.tar.bz2 md5sum: a23f331f36ff78c8bffd37973fbfbb28 glib-2.15.5.tar.gz md5sum: 113f1e8fd72dd80a5348c4da64445537 This is the sixth development release leading up to GLib 2.16. Notes: * This is unstable development release. While it has had a bit of testing, there are certainly plenty of bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of GLib 2.14. If you have problems, you'll need to reinstall GLib 2.14. * GLib 2.16 will be source and binary compatible with the GLib 2.14 series. The new API in GLib should be stable at this point; but there may still be incompatibilities between this release and the final 2.16 release. * Bugs should be reported to http://bugzilla.gnome.org. About GLib == GLib is the low-level core library that forms the basis for projects such as GTK+ and GNOME. It provides data structure handling for C, portability wrappers, and interfaces for such runtime functionality as an event loop, threads, dynamic loading, and an object system. More information about GLib is available at: http://www.gtk.org/ An installation guide for the GTK+ libraries, including GLib, can be found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Overview of Changes from GLib 2.15.4 to GLib 2.15.5 === * Update the included PCRE to 7.6 * GIO: - g_volume_should_automount: new function to determine if a volume should be mounted automatically - g_file_query_default_handler: new convenience function to get the default handler for a file - g_app_info_launch_default_for_uri new convenience function to launch the default handler for a URI - Use mimeapps.list and defaults.list as discussed on xdg list recently - g_app_info_get_default_for_uri_scheme has a real implementation now (gvfs provides a GConf-based implementation) - There is the beginning of a test suite - standard::description: new file attribute - GMountMountFlags flags argument added to mount calls * GObject: - class initialization is now threadsafe * Updated translations: Arabic (ar) Catalan (ca) Spanish (es) Basque (eu) Italian (it) Japanese (ja) Kannada (kn) Korean (ko) Macedonian (mk) Occitan (oc) Portugese (pt) Brazilian Portugese (pt_BR) Swedish (sv) Thai (th) Thanks to all contributors: Simon Murray Sebastian Wilhelmi Tim Janik Christian Persch Wouter Bolsterlee Michael Natterer Johan Dahlin Sebastian Dröge Hans Breuer Jonathon Jongsma Tor Lillqvist Murray Cumming Behdad Esfahbod Ryan Lortie Alexander Larsson Jens Granseuer Cosimo Cecchi Tomas Bzatek February 11, 2008 Matthias Clasen ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
RE: Does gtk have issues with STL?
Myself, I avoid the enter/leave calls in favor of g_idle_add() as a
mechanism to queue all gui calls for the main event loop thread. Let
your other threads stick to performing the non-gui work, and you'll save
yourself from many headaches. (I wish someone told me that 3 years ago).
BTW, I always use STL and GTK+ together. Never had a problem.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Lindley M French
Sent: Monday, February 11, 2008 5:23 PM
To: gtk-list@gnome.org
Subject: Re: Does gtk have issues with STL?
I had already figured out that widgets had to be created in the main
thread, or else the event loop wouldn't handle them. I did not realize
that one had to be careful with updating widgets as well! That explains
a few things.
So gdk_threads_enter() should be called around data updates. But is that
called automatically in default signal handlers, or do I need to put it
there myself as well? It feels odd locking only one thread explicitly.
Also, may I assume that calls made in the thread containing the event
loop don't need this protection?
- Original Message -
From: Paul Davis <[EMAIL PROTECTED]>
Date: Monday, February 11, 2008 4:49 pm
Subject: Re: Does gtk have issues with STL?
>
> On Mon, 2008-02-11 at 15:45 -0500, Lindley M French wrote:
>
> > I suspect these are merely symptoms of some other corruption,
> but I can't seem to find it.
>
> with a 99.872% confidence level, i can confirm your belief.
>
> > I'm using pthreads with this; nothing complex, and I think I
> have everything mutex'd, but it did make me wonder: Does GTK use
> gthreads internally, and is there any issue with using gthreads and
> pthreads at the same time?
>
> if you don't understand the answer to this already, it suggests that
> it may be unwise for you to be using threads at all.
>
> the use of threads in GUI toolkits that originated in the X Window
> worldis generally quite difference than the use of it with GUI
> toolkits that originated in the win32 world. in particular, the
> general rule in GTK
> is:
>
> EITHER make GTK/GDK/X11 calls from a single thread only OR use
> GDK_THREADS_{ENTER,LEAVE} around every (group of) GTK/GDK/X11
> call(s).
>
> googling will turn up plenty of refs to this stuff.
>
>
> > Also: Is it bad to emit a signal while in a signal handler
> callback? In this case I'd like to make sure a scrollbar value- update
> takes place every time a bounds-update does.
>
> in general, its not a problem. there are some specific instances where
> it can be an issue.
>
>
>
>
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Does gtk have issues with STL?
I had already figured out that widgets had to be created in the main thread, or
else the event loop wouldn't handle them. I did not realize that one had to be
careful with updating widgets as well! That explains a few things.
So gdk_threads_enter() should be called around data updates. But is that called
automatically in default signal handlers, or do I need to put it there myself
as well? It feels odd locking only one thread explicitly.
Also, may I assume that calls made in the thread containing the event loop
don't need this protection?
- Original Message -
From: Paul Davis <[EMAIL PROTECTED]>
Date: Monday, February 11, 2008 4:49 pm
Subject: Re: Does gtk have issues with STL?
>
> On Mon, 2008-02-11 at 15:45 -0500, Lindley M French wrote:
>
> > I suspect these are merely symptoms of some other corruption,
> but I can't seem to find it.
>
> with a 99.872% confidence level, i can confirm your belief.
>
> > I'm using pthreads with this; nothing complex, and I think I
> have everything mutex'd, but it did make me wonder: Does GTK use
> gthreads internally, and is there any issue with using gthreads
> and pthreads at the same time?
>
> if you don't understand the answer to this already, it suggests
> that it
> may be unwise for you to be using threads at all.
>
> the use of threads in GUI toolkits that originated in the X Window
> worldis generally quite difference than the use of it with GUI
> toolkits that
> originated in the win32 world. in particular, the general rule in GTK
> is:
>
> EITHER make GTK/GDK/X11 calls from a single thread only OR
> use GDK_THREADS_{ENTER,LEAVE} around every (group of) GTK/GDK/X11
> call(s).
>
> googling will turn up plenty of refs to this stuff.
>
>
> > Also: Is it bad to emit a signal while in a signal handler
> callback? In this case I'd like to make sure a scrollbar value-
> update takes place every time a bounds-update does.
>
> in general, its not a problem. there are some specific instances where
> it can be an issue.
>
>
>
>
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Does gtk have issues with STL?
On Mon, 2008-02-11 at 15:45 -0500, Lindley M French wrote:
> I suspect these are merely symptoms of some other corruption, but I can't
> seem to find it.
with a 99.872% confidence level, i can confirm your belief.
> I'm using pthreads with this; nothing complex, and I think I have everything
> mutex'd, but it did make me wonder: Does GTK use gthreads internally, and is
> there any issue with using gthreads and pthreads at the same time?
if you don't understand the answer to this already, it suggests that it
may be unwise for you to be using threads at all.
the use of threads in GUI toolkits that originated in the X Window world
is generally quite difference than the use of it with GUI toolkits that
originated in the win32 world. in particular, the general rule in GTK
is:
EITHER make GTK/GDK/X11 calls from a single thread only OR
use GDK_THREADS_{ENTER,LEAVE} around every (group of) GTK/GDK/X11
call(s).
googling will turn up plenty of refs to this stuff.
> Also: Is it bad to emit a signal while in a signal handler callback? In this
> case I'd like to make sure a scrollbar value-update takes place every time a
> bounds-update does.
in general, its not a problem. there are some specific instances where
it can be an issue.
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Does gtk have issues with STL?
For the moment, getting Linux to work seems like more trouble than its worth; so Valgrind is out for now. I'll revisit that option tomorrow, when someone who's used GTK on Linux before will be around. I've set Visual Studio's debug level to 3, and I'm not getting any warnings that way. On level 4 I get "unreferenced formal parameter" all over the place, and a few others, but nothing that looks important. Although behavior is still somewhat inconsistent, I have found one thing which seems to cause or remove the problem depending on its inclusion: gtk_button_set_label(GTK_BUTTON(radiobutton),"Dummy"); radiobutton is, naturally, a GtkRadioButton. This function gets called a number of times, to change the button's label depending on what's being shown in the associated window. (The radio button's purpose is to select which window gets the current input.) The "Dummy" text isn't what's supposed to go there, but the problem occurs even with it. The GTK_BUTTON typecast does not produce an error. Another place where a similar issue appears to hold is: gtk_list_store_set(store, &last, 0, "Dummy", -1); Including this causes issuessometimes it'll say "gsignal.c 650 emmission_pop should not be reached, aborting" (or something like that), sometimes it'll say there's a disparity between the list view and the store. It *is* okay to update the store after it's been attached to the tree view, isn't it? Or do I need to stick a mutex in the view redraw function? I suspect these are merely symptoms of some other corruption, but I can't seem to find it. I'm using pthreads with this; nothing complex, and I think I have everything mutex'd, but it did make me wonder: Does GTK use gthreads internally, and is there any issue with using gthreads and pthreads at the same time? Also: Is it bad to emit a signal while in a signal handler callback? In this case I'd like to make sure a scrollbar value-update takes place every time a bounds-update does. - Original Message - From: Chris MacGregor <[EMAIL PROTECTED]> Date: Friday, February 8, 2008 3:12 pm Subject: Re: Does gtk have issues with STL? > If it's not completely impractical, you might consider debugging > on > Linux a bit - there you can use Valgrind (probably worth the > effort to > port it over just for that, if it takes less than several days), > and if > you're multi-threaded, Helgrind (get the very latest release) as > well > might help you quite a bit. > > Sounds like you're dealing with race conditions (or could be > memory > corruption, of course). Valgrind/Helgrind could find your problems. > > On 02/08/2008 11:50 AM, Lindley M French wrote: > > I'd love to think it's my own source code. However, the > randomness of the errors I get (or sometimes, don't get) prevents > me from easily tracking them down. Is there some randomization at > work inside GTK? I can't see why there would be, but it's the only > thing I can think of that would cause the same binary code to > produce different behavior on successive runs. > > > > And I can't form a test case until I know what triggers the > crash, because otherwise I won't know if absence of a crash is > evidence that the test is working or not. > > > > If I had GTK source code to break on, it would make things > easier. However, the distribution I'm using didn't come with > source, and my attempts to compile the source releases I've found > have so far been unsuccessful. Bloody Windows. > > > > - Original Message - > > From: Murray Cumming <[EMAIL PROTECTED]> > > Date: Friday, February 8, 2008 1:26 pm > > Subject: Re: Does gtk have issues with STL? > > > > > >> On Fri, 2008-02-08 at 10:44 -0500, Lindley M French wrote: > >> > >>> The instability I was seeing before might have been due to my > >>> > >> use of an STL map to maintain my list of available windows. Is > >> this a known issue, or should I be looking elsewhere? > >> > >>> I'm suspicious because several of the errors I've gotten > >>> > >> (they're different each time, even if I don't recompile) have > >> related to reference counting errors. Since STL maintains some > >> internal state, there might be something going on there. > >> > >> No, this doesn't make any sense. > >> > >> You have probably made errors in your own source code. You > should try > >> valgrind and/or try to reduce it to a simple test case. > >> > >> -- > >> [EMAIL PROTECTED] > >> www.murrayc.com > >> www.openismus.com > >> > >> > > ___ > > gtk-list mailing list > > gtk-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/gtk-list > > > ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GtkRecentChooserMenu gtk_widget_show_all() misbehaviour
On Mon, 2008-02-11 at 09:29 +0100, Stephan Arts wrote: > It seems to me that this is a bug, am I correct? yes, it is. but next time open a bug in bugzilla instead of using the mailing list (it's easier to track). I've committed a fix in trunk and in the gtk-2-12 branch. ciao, Emmanuele. -- Emmanuele Bassi, W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
GtkRecentChooserMenu gtk_widget_show_all() misbehaviour
Hi, I noticed that the GtkRecentChooserMenu makes the internal widget that displays the 'no items found' message even though there are items inside the menu when using gtk_widget_show_all. It happens with gtk 2.12 (while it did not with 2.10 iirc). It seems to me that this is a bug, am I correct? Here's a screenshot: [0] Regards, Stephan [0] http://mocha.foo-projects.org/~stephan/recent-screenshot.png ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
