GNOME Bugzilla – Bug 581288
Use GtkBuilder instead of libglade
Last modified: 2010-11-12 06:29:39 UTC
See http://live.gnome.org/GnomeGoals/RemoveLibGladeUseGtkBuilder . grep -r glade . ./evolution-data-server-zip.in:share/evolution-data-server-@BASE_VERSION@/glade/e-categories-dialog.glade ./evolution-data-server-zip.in:share/evolution-data-server-@BASE_VERSION@/glade/e-name-selector-dialog.glade ./libedataserver/Makefile.am: -DE_DATA_SERVER_UI_GLADEDIR=\""$(gladedir)"\" \ ./libedataserver/e-data-server-util.c:static const char *ui_gladedir; ./libedataserver/e-data-server-util.c: ui_gladedir = replace_prefix (prefix, E_DATA_SERVER_UI_GLADEDIR); ./libedataserver/e-data-server-util.c:PRIVATE_GETTER(ui_gladedir) ./libedataserver/libedataserver-private.h:const char *_libedataserver_get_ui_gladedir (void) G_GNUC_CONST; ./libedataserver/libedataserver-private.h:#define E_DATA_SERVER_UI_GLADEDIR _libedataserver_get_ui_gladedir () ./configure.in:m4_define([libglade_minimum_version], [2.0.0]) # XXX Just a Guess ./configure.in: libglade-2.0 >= libglade_minimum_version ./configure.in:E_DATA_SERVER_UI_DEPS="gtk+-2.0 libglade-2.0 gobject-2.0 gthread-2.0 gconf-2.0 $GNOME_KEYRING_REQUIREMENT" ./configure.in:gladedir="$privdatadir/glade" ./configure.in:AC_SUBST(gladedir) ./libedataserverui/e-categories-dialog.glade:<!DOCTYPE glade-interface SYSTEM "http://glade.gnome.org/glade-2.0.dtd"> ./libedataserverui/e-categories-dialog.glade:<glade-interface> ./libedataserverui/e-categories-dialog.glade:</glade-interface> ./libedataserverui/e-name-selector-dialog.h:#include <glade/glade.h> ./libedataserverui/e-name-selector-dialog.c: combo_box = glade_xml_get_widget ( ./libedataserverui/e-name-selector-dialog.c: char *gladefile; ./libedataserverui/e-name-selector-dialog.c: gladefile = g_build_filename (E_DATA_SERVER_UI_GLADEDIR, ./libedataserverui/e-name-selector-dialog.c: "e-name-selector-dialog.glade", ./libedataserverui/e-name-selector-dialog.c: name_selector_dialog->gui = glade_xml_new (gladefile, NULL, GETTEXT_PACKAGE); ./libedataserverui/e-name-selector-dialog.c: g_free (gladefile); ./libedataserverui/e-name-selector-dialog.c: widget = glade_xml_get_widget (name_selector_dialog->gui, "name-selector-box"); ./libedataserverui/e-name-selector-dialog.c: glade_xml_get_widget (name_selector_dialog->gui, "source-tree-view")); ./libedataserverui/e-name-selector-dialog.c: glade_xml_get_widget (name_selector_dialog->gui, "status-message")); ./libedataserverui/e-name-selector-dialog.c: glade_xml_get_widget (name_selector_dialog->gui, "destination-box")); ./libedataserverui/e-name-selector-dialog.c: glade_xml_get_widget (name_selector_dialog->gui, "search")); ./libedataserverui/e-name-selector-dialog.c: label = glade_xml_get_widget (name_selector_dialog->gui, "AddressBookLabel"); ./libedataserverui/e-name-selector-dialog.c: container = glade_xml_get_widget (name_selector_dialog->gui, "source-menu-box"); ./libedataserverui/e-name-selector-dialog.c: widget = glade_xml_get_widget (name_selector_dialog->gui, "search"); ./libedataserverui/e-name-selector-dialog.c: combo_box = glade_xml_get_widget ( ./libedataserverui/libedataserverui.pc.in:Requires: gtk+-2.0 libglade-2.0 libedataserver-@API_VERSION@ libebook-@API_VERSION@ ./libedataserverui/Makefile.am: -DE_DATA_SERVER_UI_GLADEDIR=\""$(gladedir)"\" \ ./libedataserverui/Makefile.am:glade_DATA = e-categories-dialog.glade e-name-selector-dialog.glade ./libedataserverui/Makefile.am: $(glade_DATA) \ ./libedataserverui/e-categories-dialog.c:#include <glade/glade-xml.h> ./libedataserverui/e-categories-dialog.c: char *gladefile; ./libedataserverui/e-categories-dialog.c: gladefile = g_build_filename (E_DATA_SERVER_UI_GLADEDIR, ./libedataserverui/e-categories-dialog.c: "e-categories-dialog.glade", ./libedataserverui/e-categories-dialog.c: prop_dialog->gui = glade_xml_new (gladefile, "properties-dialog", GETTEXT_PACKAGE); ./libedataserverui/e-categories-dialog.c: g_free (gladefile); ./libedataserverui/e-categories-dialog.c: prop_dialog->the_dialog = glade_xml_get_widget (prop_dialog->gui, "properties-dialog"); ./libedataserverui/e-categories-dialog.c: prop_dialog->category_name = glade_xml_get_widget (prop_dialog->gui, "category-name"); ./libedataserverui/e-categories-dialog.c: prop_dialog->category_icon = glade_xml_get_widget (prop_dialog->gui, "category-icon"); ./libedataserverui/e-categories-dialog.c: char *gladefile; ./libedataserverui/e-categories-dialog.c: gladefile = g_build_filename (E_DATA_SERVER_UI_GLADEDIR, ./libedataserverui/e-categories-dialog.c: "e-categories-dialog.glade", ./libedataserverui/e-categories-dialog.c: priv->gui = glade_xml_new (gladefile, "table-categories", GETTEXT_PACKAGE); ./libedataserverui/e-categories-dialog.c: g_free (gladefile); ./libedataserverui/e-categories-dialog.c: g_warning (G_STRLOC ": can't load e-categories-dialog.glade file"); ./libedataserverui/e-categories-dialog.c: main_widget = glade_xml_get_widget (priv->gui, "table-categories"); ./libedataserverui/e-categories-dialog.c: priv->categories_entry = glade_xml_get_widget (priv->gui, "entry-categories"); ./libedataserverui/e-categories-dialog.c: priv->categories_list = glade_xml_get_widget (priv->gui, "categories-list"); ./libedataserverui/e-categories-dialog.c: priv->new_button = glade_xml_get_widget (priv->gui, "button-new"); ./libedataserverui/e-categories-dialog.c: priv->edit_button = glade_xml_get_widget (priv->gui, "button-edit"); ./libedataserverui/e-categories-dialog.c: priv->delete_button = glade_xml_get_widget (priv->gui, "button-delete"); ./libedataserverui/e-name-selector-dialog.glade:<!DOCTYPE glade-interface SYSTEM "http://glade.gnome.org/glade-2.0.dtd"> ./libedataserverui/e-name-selector-dialog.glade:<glade-interface> ./libedataserverui/e-name-selector-dialog.glade:</glade-interface> ./servers/exchange/storage/Makefile.am: -DCONNECTOR_GLADEDIR=\""$(gladedir)"\" \ ./servers/exchange/storage/exchange-folder-size.c:#include <glade/glade-xml.h> ./servers/exchange/storage/exchange-account.c:#include <glade/glade-xml.h>
The question is whether it's portable or not... The main problem is that not everything what is supported in libglade is supported in gtkbuilder. So first the glade files must be edited to be fully portable ( for example Gnome Druid, tooltips on object etc ) then the actual code migration can take place... And then happy testing of course. This will ( I think ) also change visible things as some things must be replaced in the glade files. These are the glade files : ./filter/filter.glade ./shell/importer/import.glade ./shell/e-active-connection-dialog.glade ./shell/import.glade ./addressbook/gui/contact-list-editor/contact-list-editor.glade ./addressbook/gui/component/ldap-config.glade ./addressbook/gui/merging/eab-contact-commit-duplicate-detected.glade ./addressbook/gui/merging/eab-contact-duplicate-detected.glade ./addressbook/gui/contact-editor/fullname.glade ./addressbook/gui/contact-editor/contact-editor.glade ./plugins/groupwise-features/proxy-add-dialog.glade ./plugins/groupwise-features/junk-settings.glade ./plugins/groupwise-features/properties.glade ./plugins/groupwise-features/proxy-listing.glade ./plugins/groupwise-features/proxy-login-dialog.glade ./plugins/exchange-operations/exchange-folder-tree.glade ./plugins/exchange-operations/exchange-delegates.glade ./plugins/exchange-operations/exchange-change-password.glade ./plugins/exchange-operations/e-foreign-folder-dialog.glade ./plugins/exchange-operations/exchange-permissions-dialog.glade ./plugins/exchange-operations/exchange-send-options.glade ./plugins/exchange-operations/exchange-oof.glade ./plugins/exchange-operations/exchange-passwd-expiry.glade ./plugins/templates/templates.glade ./plugins/attachment-reminder/attachment-reminder.glade ./plugins/email-custom-header/email-custom-header.glade ./plugins/email-custom-header/org-gnome-email-custom-header.glade ./plugins/publish-calendar/publish-calendar.glade ./plugins/imap-features/imap-headers.glade ./calendar/gui/goto-dialog.glade ./calendar/gui/dialogs/e-delegate-dialog.glade ./calendar/gui/dialogs/event-page.glade ./calendar/gui/dialogs/cal-prefs-dialog.glade ./calendar/gui/dialogs/schedule-page.glade ./calendar/gui/dialogs/alarm-list-dialog.glade ./calendar/gui/dialogs/task-details-page.glade ./calendar/gui/dialogs/memo-page.glade ./calendar/gui/dialogs/recurrence-page.glade ./calendar/gui/dialogs/task-page.glade ./calendar/gui/dialogs/alarm-dialog.glade ./calendar/gui/alarm-notify/alarm-notify.glade ./calendar/gui/e-itip-control.glade ./smime/gui/smime-ui.glade ./mail/mail-config.glade ./mail/mail-dialogs.glade ./designs/OOA/ooa.glade ./designs/read_receipts/read.glade ./widgets/table/e-table-config.glade ./widgets/table/e-table-field-chooser.glade ./widgets/misc/e-send-options.glade ./widgets/menus/gal-view-instance-save-as-dialog.glade ./widgets/menus/gal-define-views.glade ./widgets/menus/gal-view-new-dialog.glade ./widgets/e-timezone-dialog/e-timezone-dialog.glade ;) :-) Who wants it *rofl*
It can be mostly automated once we get the other libgnomeui bugs closed.
(In reply to comment #1) > These are the glade files : [...] Those were the glade files in Evolution, but this bug is about Evolution-Data-Server. In general: See http://www.gnome.org/~fpeters/299.html for the overall status in GNOME for 3.0.
Created attachment 141245 [details] [review] proposed eds patch for evolution-data-server; pretty simple on eds. Only two things I'm not sure about: a) I changed 'gladedir' to 'uidir' in configure.ac and store .ui files into 'ui' directory. That's no issue here, I think, just evo will need other directory, as it is using 'ui' directory for other things. I would like to keep this consistent in evo and eds, thus bringing it here. b) I changed E_DATA_SERVER_UI_GLADEDIR to E_DATA_SERVER_UI_UIDIR
Haven't looked closely at the XML or code changes, but the configure.ac / Makefile.am changes look perfectly fine to me. As a long-term goal we might consider getting rid of the UI files in libedataserverui and just building the dialogs manually. Having to load UI files in a reusable widget library is kind of awkward.
I think the patch is safe to commit. Just give it some light testing to make sure the dialogs work.
(In reply to comment #6) > Just give it some light testing to make sure the dialogs work. Yup, I did before posting the patch :)
Created commit 4ef00fe in eds master (2.29.1+)
The .ui files are missing in the commit, and please update POTFILES.in accordingly.
Created commit 0cd5905 in eds master (2.29.1+) Bad of me. Thanks for letting me know so quickly.
Thanks, I just added the gettext/glade prefix to .ui files in POTFILES.in :-P intltool does not know automatically how to properly handle .ui files.
(In reply to comment #11) > Thanks, I just added the gettext/glade prefix to .ui files in POTFILES.in :-P > intltool does not know automatically how to properly handle .ui files. huh, bad of me. But I will try the thing Matt suggested in comment #5, not using ui files at all. It seems to be pretty simple to do. Let's see.
Regression in Evo build. Bug #592551 Either include the glade header in there or use GtkBuilder for that plugin alone. Other plugins all look fine.
Created attachment 141319 [details] [review] proposed eds patch for evolution-data-server; This patch is to not use the .ui files at all in eds. Note that I broke ABI in libedataserverui/e-name-selector-dialog.h The necessary changes (only two) in evo had been done already, with the build break fix, which is in sources now.
Long as we're breaking ABI anyway to kill off ESourceOptionMenu, I'm all for sealing up the rest of the widget classes. Note that the public struct should still include a pointer to the (opaque) private structure for easier debugging: struct _ENameSelectorDialog { GtkDialog parent; ENameSelectorDialogPrivate *priv; }; Let's wait until the November decision on whether 3.0 == 2.30 or 2.32 before proceeding with this. I'd rather pack as much as we can into one big API/ABI break than have multiple breaks for small changes.
is it too late now?
Milan, it's never too late for us, but let's break ABI for 2.31 as 2.32==3.0.
Changing the version.
(In reply to comment #15) > Long as we're breaking ABI anyway to kill off ESourceOptionMenu, I'm all for > sealing up the rest of the widget classes. > Let's wait until the November decision on whether 3.0 == 2.30 or 2.32 before > proceeding with this. I'd rather pack as much as we can into one big API/ABI > break than have multiple breaks for small changes. Ping - should this be done now?
All clear to proceed with Milan's patch. It's open season on API cleanups this cycle.
Created commit 15a7dd0 in eds master (2.91.3+) .ui files from eds are gone now. Sources changed meanwhile, thus a little changes were required, but nothing undoable.