GSlice: g_thread_init() must be called before all other GLib functions;
Hi, I get the following error message when running my GTK app: GSlice: g_thread_init() must be called before all other GLib functions; memory corruption due to late invocation of g_thread_init() has been detected; this program is likely to crash, leak or unexpectedly abort soon... I read herehttp://blogs.gnome.org/timj/2007/01/02/28122006-g_slicedebug-blocks/that the correct workaround is to call g_thread_init(NULL). However, when I try to do that I get an undefined reference to g_thread_init error. And this happens even if I include glib.h. I did a grep on the header files I have in /usr/include and got this: glib-1.2/glib.h:void g_thread_init (GThreadFunctions *vtable); glib-2.0/glib/gthread.h:voidg_thread_init (GThreadFunctions *vtable); glib-2.0/glib/gthread.h:voidg_thread_init_with_errorcheck_mutexes (GThreadFunctions* vtable); glib-2.0/glib/gthread.h:#define g_thread_init(vtable) g_thread_init_with_errorcheck_mutexes (vtable) glibmm-2.4/glibmm/thread.h: g_thread_init(vtable); grep: warning: lua50/lua: recursive directory loop So I added the corresponding headers: #include glib-2.0/glib/gthread.h #include glib-1.2/glib.h But I still get the undefined reference error. After some printf debugging, I traced the origin of the warning to the creation of a filechooser button. And when I create a new GTK project with Anjuta+Glade2 and place a filechooser button, I do indeed always get this warning. How can I get rid of this warning the correct way? Where am I supposed to place the g_thread_init() call? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GSlice: g_thread_init() must be called before all other GLib functions;
On Tue, 2007-06-19 at 15:53 +0200, John Zoidberg wrote: [...] How can I get rid of this warning the correct way? Where am I supposed to place the g_thread_init() call? Put it before gtk_init(), and before initializing any libraries that might also use threading. The undefined reference error you are getting looks like a link error, not a compiler error. Is it possible that you have a glib compiled without threads ? or that your libgthread.so is missing or installed in a strange place ? did you compile your app to look for libgthread ? ldd myapp | grep gthread should tell you if and where your app is looking for the gthread library. Cheers, -Tristan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GSlice: g_thread_init() must be called before all other GLib functions;
On Tue, Jun 19, 2007 at 03:53:30PM +0200, John Zoidberg wrote: I get the following error message when running my GTK app: GSlice: g_thread_init() must be called before all other GLib functions; memory corruption due to late invocation of g_thread_init() has been detected; this program is likely to crash, leak or unexpectedly abort soon... I read herehttp://blogs.gnome.org/timj/2007/01/02/28122006-g_slicedebug-blocks/that the correct workaround is to call g_thread_init(NULL). This is a bit taken out of context. This is not so much of a workaround as something you always have to do when you use threads. And you have to do this very early. And the problem was that even if people were told to do this very early, they didn't (because it had used to work and because sometimes the responsibility was not clear) -- and then GSlice came and made programs that did not call g_thread_init() early actually break. If you do not use threads, nothing of this concerns you. However, when I try to do that I get an undefined reference to g_thread_init error. And this happens even if I include glib.h. I did a grep on the header files I have in /usr/include and got this: glib-1.2/glib.h:void g_thread_init (GThreadFunctions *vtable); glib-2.0/glib/gthread.h:voidg_thread_init (GThreadFunctions *vtable); glib-2.0/glib/gthread.h:voidg_thread_init_with_errorcheck_mutexes (GThreadFunctions* vtable); glib-2.0/glib/gthread.h:#define g_thread_init(vtable) g_thread_init_with_errorcheck_mutexes (vtable) glibmm-2.4/glibmm/thread.h: g_thread_init(vtable); grep: warning: lua50/lua: recursive directory loop So I added the corresponding headers: #include glib-2.0/glib/gthread.h #include glib-1.2/glib.h Well, this is extremely fishy. Are you trying to use GLib 1.2 and 2.0 simultaneously in one program? This will not work. After some printf debugging, I traced the origin of the warning to the creation of a filechooser button. And when I create a new GTK project with Anjuta+Glade2 and place a filechooser button, I do indeed always get this warning. How can I get rid of this warning the correct way? For start, get rid of everything GLib-1.2-ish. This itself can fix the problems. Or maybe not. Where am I supposed to place the g_thread_init() call? If you use threads, or something you use uses threads, then before any other GLib call, or call to something that uses GLib (for instance to Gtk+). The very first line of main() can be a good place. And you have to add `gthread-2.0' to the list of pkg-config packages your program depends on (have no idea how to do this in Anjuta or Glade, but it typically should appear in an argument of PKG_CHECK_MODULES() in configure.ac at the end). Yeti -- http://gwyddion.net/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GTK+ 2.11.4 released
GTK+ 2.11.4 is now available for download at: ftp://ftp.gtk.org/pub/gtk/2.11/ http://ftp.gnome.org/pub/GNOME/sources/gtk+/2.11/ gtk+-2.11.4.tar.bz2 md5sum: a3baab72d34b6fa9c01578f1f2dd84f0 gtk+-2.11.4.tar.gzmd5sum: b43f01b91ff406b2cd8d009eff03a2cc This is another development release leading up to GTK+ 2.12. 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 GTK+ 2.10. If you have problems, you'll need to reinstall GTK+ 2.10. * GTK+ 2.12 will be source and binary compatible with the GTK+ 2.10 series; however, the new API additions are not yet completely finalized, so there may be incompatibilities between this release and the final 2.12 release. * Bugs should be reported to http://bugzilla.gnome.org. What is GTK+ GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. Where to get more information about GTK+ Information about GTK+ including links to documentation can be found at: http://www.gtk.org/ An installation guide for GTK+ is found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Common questions: http://developer.gnome.org/doc/API/2.0/gtk/gtk-question-index.html http://www.gtk.org/faq/ Contributing GTK+ is a large project and relies on voluntary contributions. We are actively searching for new contributors in various areas and invite everyone to help project development. If you are willing to participate, please subscribe to the project mailing lists to offer your help and read over our list of vacant project tasks: http://live.gnome.org/GtkTasks Overview of Changes from GTK+ 2.11.3 to 2.11.4 == * The multipress input method correctly handles control keys * The memory management of GtkRecentManager has been changed, deprecating the screen-related functions in favour of gtk_recent_manager_get_default(). * Bugs fixed: 448928 Some GtkBuildable methods named too generically 448193 gtkbuilder.h causes compile error with C++ 354887 GtkFileChooserButton displays unnecessary authentication ... 440450 GTK font selection minimum size is too large for 150dpi s... 447214 gtk_tooltips_widget_remove() is slow 448299 dgettext arguments interchanged 448321 Drawing problems with block cursor 448341 There is no GtkTooltip documentation in the gtk+ reference 448484 GtkAccelGroup forgets to remove closure invalidate notifi... 448544 Refcount issues in GtkCellRendererSpin 412357 GtkMenuShell not defined as an abstract base type 403717 print preview operation should pass settings to preview p... A list of all bugs fixed in this release can be found here: http://bugzilla.gnome.org/buglist.cgi?bug_id=448193,448299,448321,440450,63820,403717,354887,412357,448484,448544,448928,447214,448341 Thanks to all contributors: Christian Persch Richard Hult Johan Dahlin Jan Arne Petersen Yevgen Muntyan Sebastien Bacher Alex Jones Behdad Esfahbod Daniel Elstner Tilman Sauerbeck Xan Lopez Carlos Garcia Campos Dennis Cranston Vincent Geddes Gustavo J. A. M. Carneiro Carlos Garnacho Emmanuele Bassi Torsten Schoenfeld Sven Neumann Matthias Clasen June 19, 2007 ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Which widget to use for creating a list
Hi, i m new to GTK+ i am working on GTK+ with directfb on embedded platform. i want to have a list of say 4-5 items which can be selected by the direction keys..so that the selection moves to next one as u press the down key or moves up with the up key... I guess i need selectable text here..but i m not able to determine how to implement this in GTK.. Plz help me out n suggest the widget structure. Thanks in advance. Regards, Prateek Mathur The information contained in this mail is classified as ( ) LT Infotech Proprietary ( ) LT Infotech Confidential ( ) LT Infotech Internal Use (x) LT Infotech General Business __ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK+ 2.11.3 released
Am Montag, den 18.06.2007, 19:08 -0600 schrieb Elijah Newren: On 6/18/07, Hubert Figuiere [EMAIL PROTECTED] wrote: I don't agree with that one. It is much simplier to add a C++ compile test. Afterall, which platform does not have a C++ compiler? Why reinventing the wheel yet again to make it square? Do all embedded platforms have a C++ compiler? And are there really that many C++-specific keywords? You are missing the point. This test would be run by make check to prevent that the maintainer releases code having C++ keywords in its headers. Regular users would not be affected by this test. Created a Bugzilla ticket: http://bugzilla.gnome.org/show_bug.cgi?id=449016 Potential implementation of the test: http://bugzilla.gnome.org/attachment.cgi?id=90258 Ciao, Mathias PS: Pardon for spaming, but seems like Evolution enjoys it to randomly choose my sender address. The taschenorakel address is not subscribed to gtk-devel list. -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder Public API - Last call
Torsten Schoenfeld wrote: On Mon, 2007-06-18 at 09:55 -0300, Johan Dahlin wrote: void (* set_property)(GtkBuildable *buildable, GtkBuilder*builder, const gchar *name, const GValue *value); This collides with GObject::set_property. Maybe set_buildable_property? or buildable_set_property. I think C coders will dislike gtk_buildable_buildable_set_property. :-) Can you open a bug and set it as a blocker? Sure: http://bugzilla.gnome.org/show_bug.cgi?id=448928 Thanks a lot! Committed on trunk. Johan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: 'reloading' gtktreeview when model changes drastically
CC'd the -devel list as I think this is relevant there.. On Tue, 2007-06-19 at 11:56 +1000, Daniel Kasak wrote: On Thu, 2007-06-14 at 21:54 +0200, [EMAIL PROTECTED] wrote: [snip] The data model often changes drastically, a lot of rows and subtrees are modified, deleted, created, etc. If you change the model significantly, you want to do one of 2 things. Option 1 ) Create a new model, populate it, and then use gtk_tree_view_set_model to tell the treeview about the new model, and dump the old one. Option 2 ) use gtk_tree_view_set_model to point the treeview at another ( empty ) model ( or maybe NO model ... I'm not sure if you can do this, I've never tried it ). Then do your changes to the real model. Then use gtk_tree_view_set_model once more to point the treeview back at the real model. The idea with both of these approaches is that when you do lots of changes to the model, it forces the treeview to keep updating, and this is slow. It's best to do all your changes with the treeview *disconnected* from the model, and then connect it back. Works for me anyway. This seems to break the MVC abstraction - if the model changes drastically, I need to know which tree-views are connected so I can disconnect them? Bad! We need some new API I guess - which signals any connected views that the data it has cached about the model should be invalidated, and that the model may be changing without emitting signals. Once the model is updated, a further signal will inform the view that it can keep cached state again. Here is a possible interaction flow... Model: Emits invalidate signal View: Knows its internal state may loose track with the model, if it needs to ask the model for any information, it must not assume the model's state. Model: Re-populates without emitting any changed type signals View: (What does it do whilst we're repopulating??) Model: Still repopulating without emitting any changed type signals Model: Emits a some signal to notify that it has finished - any further updates emit changed type signals. View: Redraws? Anyway - the design might suck - IANACS (CS= Computer Scientist). Adding support of the new signal to the GtkTreeView ought not to break existing API, as old models just won't emit that signal. (IANAGTKDeveloper, so could be wrong about that). Regards, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Blacklisting themes?
In light of bug 438456, is there (or should there be) a way to blacklist a certain theme engine for a certain version range? Bug 438456 causes memory corruption in any gtk+ application it is applied to. Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GTK+ 2.11.4 released
GTK+ 2.11.4 is now available for download at: ftp://ftp.gtk.org/pub/gtk/2.11/ http://ftp.gnome.org/pub/GNOME/sources/gtk+/2.11/ gtk+-2.11.4.tar.bz2 md5sum: a3baab72d34b6fa9c01578f1f2dd84f0 gtk+-2.11.4.tar.gzmd5sum: b43f01b91ff406b2cd8d009eff03a2cc This is another development release leading up to GTK+ 2.12. 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 GTK+ 2.10. If you have problems, you'll need to reinstall GTK+ 2.10. * GTK+ 2.12 will be source and binary compatible with the GTK+ 2.10 series; however, the new API additions are not yet completely finalized, so there may be incompatibilities between this release and the final 2.12 release. * Bugs should be reported to http://bugzilla.gnome.org. What is GTK+ GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. Where to get more information about GTK+ Information about GTK+ including links to documentation can be found at: http://www.gtk.org/ An installation guide for GTK+ is found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Common questions: http://developer.gnome.org/doc/API/2.0/gtk/gtk-question-index.html http://www.gtk.org/faq/ Contributing GTK+ is a large project and relies on voluntary contributions. We are actively searching for new contributors in various areas and invite everyone to help project development. If you are willing to participate, please subscribe to the project mailing lists to offer your help and read over our list of vacant project tasks: http://live.gnome.org/GtkTasks Overview of Changes from GTK+ 2.11.3 to 2.11.4 == * The multipress input method correctly handles control keys * The memory management of GtkRecentManager has been changed, deprecating the screen-related functions in favour of gtk_recent_manager_get_default(). * Bugs fixed: 448928 Some GtkBuildable methods named too generically 448193 gtkbuilder.h causes compile error with C++ 354887 GtkFileChooserButton displays unnecessary authentication ... 440450 GTK font selection minimum size is too large for 150dpi s... 447214 gtk_tooltips_widget_remove() is slow 448299 dgettext arguments interchanged 448321 Drawing problems with block cursor 448341 There is no GtkTooltip documentation in the gtk+ reference 448484 GtkAccelGroup forgets to remove closure invalidate notifi... 448544 Refcount issues in GtkCellRendererSpin 412357 GtkMenuShell not defined as an abstract base type 403717 print preview operation should pass settings to preview p... A list of all bugs fixed in this release can be found here: http://bugzilla.gnome.org/buglist.cgi?bug_id=448193,448299,448321,440450,63820,403717,354887,412357,448484,448544,448928,447214,448341 Thanks to all contributors: Christian Persch Richard Hult Johan Dahlin Jan Arne Petersen Yevgen Muntyan Sebastien Bacher Alex Jones Behdad Esfahbod Daniel Elstner Tilman Sauerbeck Xan Lopez Carlos Garcia Campos Dennis Cranston Vincent Geddes Gustavo J. A. M. Carneiro Carlos Garnacho Emmanuele Bassi Torsten Schoenfeld Sven Neumann Matthias Clasen June 19, 2007 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Blacklisting themes?
On 6/19/07, Morten Welinder [EMAIL PROTECTED] wrote: In light of bug 438456, is there (or should there be) a way to blacklist a certain theme engine for a certain version range? Bug 438456 causes memory corruption in any gtk+ application it is applied to. I don't see how this is different from any other memory corrupting bug in, say, a library. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Blacklisting themes?
I don't see how this is different from any other memory corrupting bug in, say, a library. From a technical standpoint it is not. However, a theme is a library that is loaded into your application by the end-user. Even if he is not particularly aware of doing so. The application programmer has no choice in the matter and cannot really test with all kinds of themes and all kinds of versions of them. But the resulting crashes are still going to be blamed on the application and poor me. Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
