GNOME Bugzilla – Bug 161903
Patch from glade-3 people
Last modified: 2011-07-03 08:15:35 UTC
Hi, this patch includes: * glade-init.c: Fix for applications to load properly under win32 (Ivan Wong <email@ivanwong.info>) * glade-parser.[ch]: Implement loading of glade files for glade-3 (Ivan Wong <email@ivanwong.info>) * glade-xml.c: Non widget fix (This implements non-widgets cleanly but does not change function signatures and variable names library wide from "GtkWidget *widget" to "GObject *object"). * glade-private.h,glade-xml.c: Implementation of g_module_lookup for signal handler user_data arguments.
Created attachment 35087 [details] [review] This is the patch for non-widgets/glade-3 glade file loading & friends
*** Bug 156612 has been marked as a duplicate of this bug. ***
Created attachment 35370 [details] [review] Patch replacement (enhancement) This replacement patch adds fine grained error handleing upon saveing a GladeInterface to the last patch (all in one).
I just noticed that the patch uses g_filename_display_name, which was added in glib 2.6. I guess we should either branch libglade and add a check for 2.6 or change the patch so it applies without glib 2.6.
libglade cvs already demands glib 2.5.0 (dev release), g_filename_display_name is present since cvs tag GLIB_2_5_5, So, yes the configure.in should be updated to demand 2.5.5; I'll try to do that later today.
Just noting here so I don't forget, there's a bug in the patch, in glade_xml_set_common_params(): g_object_weak_ref (G_OBJECT (widget), (GWeakNotify)glade_xml_finalize_notify, dd); g_object_add_weak_pointer (G_OBJECT (self), (gpointer *)&(dd->xml)); The location of the weak pointer is freed by glade_xml_finalize_notify() when it tries to nullify it so it frees unallocated data, causing random crashes.
A patch for the patch: if (dd->xml) { + g_object_remove_weak_pointer (G_OBJECT (dd->xml), (gpointer *)&(dd->xml)); g_hash_table_remove(dd->xml->priv->name_hash, dd->name); } in glade_xml_finalize_notify().
I brought up a few issues on the glade mailing list that need to be addressed for this approach to work. The three most important ones are: 1. When loading files in glade-3 strings need to be kept as the original, untranslated/unstripped strings, otherwise the translated strings will show up in glade-3 and will also be saved as original strings when saving. 2. The i18n metadata (translatable, comment, context) that is currenly thrown away after getting the strings in libglade needs to be kept for at least the GladeInterface stage so that glade-3 can access them. This must be done without changing the exposed structs etc, since third-party modules access this for libglade modules. 3. The changes to the API in the patch needs to be reverted for the same reason as above, the API is used by modules such as libgnomeui/libgnomecanvas/libbonoboui, and perhaps other unknown third party modules.
James, what are your thoughts on this?
> 3. The changes to the API in the patch needs to be reverted What API changes? Do you mean the changes to _GladeProperty and _GladeSignalInfo?
Yes. Although I think Tristan has given up on this approach I think?
> Do you mean the changes to _GladeProperty and _GladeSignalInfo? Yeah, these changes break the glade_register_widget()/glade_register_custom_prop() apis (since these data structures get passed to the said registered callbacks). My feelings on this matter atm is that its a snag in the wheel of glade3 development; originaly I was won over to the idealistic idea of a unified parser mechanism for applications loading glade files and applications generating glade files (I still think that this is the ultimate way to go), but it seems that the level of collaboration required for this to become a reality is too high. My plan now is to duplicate the glade file load/save mechanism in the glade-3 application and cut the dependancy to libglade, then to update this patch to only include non-widget support & g_module_lookup for user_data in signal callbacks. Thoughts ?
Created attachment 38063 [details] [review] latest patch This latest patch includes non-widget GObject support, g_module_lookup capability for user_data arguments in autoconnected signal handlers & Ivan Wong's patch for applications to startup properly under win32. FYI, glade-3 was merged back to HEAD today and there is no longer any libglade dependancy there (Thanks to Naba Kumar ;-) .
I guess this can be closed as outdated now that Glade uses GtkBuilder instead?
Yes lets close it libglade is deprecated so I guess anything that adds a feature here should be closed.