I'm already working on this for the kill-bonobo branch.

Don't bother with master.

Got this ~80% done on the branch, but got blocked by GnomeDruid and its ilk.

GnomeDruid isn't compatible with GtkBuilder at all.  It defines no properties or named children for the UI definition to reference.  libglade has special code to deal with it, GtkBuilder makes no such concessions.  So the GnomeDruid -> GtkAssistant migration (bug #567260) needs to happen first.

Hey Matthew, so the migration to GtkAssistant is done and that means this should be either FIXED or have 20% to do?

Something like that.  I'll get around to it again after kill-bonobo is merged.  Right now I'm 100% focused on calendar.

Bad news.  A bad Fedora update last weekend rendered my laptop unbootable.  I had to reinstall, and lost all my private git branches including this one.  So I'm back at square one.  It's mostly mindless gruntwork though, so I should be able to recreate the work fairly easily if I can just find a day or two.

Created attachment 142635 [details] [review]
proposed evo patch (part I, remove duplicate names)

for evolution;

as we discussed in bug #593754, I'm attaching the changes of glade files with removed duplicate widget names. It's based on a result of this command:
   for i in `find . -name *.glade` ; do { echo $i; gtk-builder-convert $i
   /dev/null | grep -v Wrote; } ; done ;

I skipped plugins/exchange-operations in favour of
patch in bug #456240 comment #18

If anyone can, please test groupwise-features/proxy-listing.glade, whether it shows the proper tab content. That's one where I'm not sure whether I chose the right widget to start build in.

I'm obsoleting the above patch, as there was done a commit for that already.
I'm wondering whether I'm able to help here anyhow. Knowing what you want to do I can help (Being it up to me, I would convert .glade files to .ui files and convert the related code properly, and if the .glade file couldn't be converted, then make it a C code).

Created commit 0b7bc98 in evo gtk-builder (the /addressbook part)

I'm safely ignoring this:
> evolution/plugins/exchange-operations/exchange-permissions-
> dialog.ui:200:                  <object class="Custom" id="role_optionmenu">

as it's not part of evo any more, and the eex code has this fixed already.

Created commit e3f9654 in evo gtk-builder (the .../widgets/table part)
Created commit 43e3968 in evo gtk-builder (the .../calendar part)

The only which lefts is the modules/addressbbok/ldap-config.ui, but it's quite broken at the moment, as the window of "Address book preferences" is shown with "New address book", and vice versa. Also not all widgets are shown when selecting ldap address book type. Thus it's almost ready for testing.

I took care of ldap-config.ui.

Only remaining task is to trigger each GtkBuilder file to be loaded in Evolution and check for any disembodied UI -- that is, stray windows appearing which shouldn't be there, like what you were seeing with "Address Book Preferences".

The story behind that is libglade requires all widgets to live in a window, whether you want the window or not.  To compensate for this silly requirement, glade_xml_new() allows you to pass a "root" widget name argument that tells libglade to only build -that- widget and all it's children.  So if the "root" widget is, say, a toolbar, the toolbar is built as an unparented widget even though it lives in a window in the Glade file.

GtkBuilder lifts the everything-has-to-live-in-a-window requirement, allowing you to build that toolbar in Glade without having to put it in a window.  But it also drops the "root" widget name feature, so when you load a GtkBuilder file you load the -whole- file.

The extra windows you were seeing were those unnecessary windows in the XML file containing widgets that we were previously loading as "root" widgets through libglade.  Because they're marked visible in the XML definition, GtkBuilder happily builds them and displays them.  So those extra windows need to be found and deleted, if there's any more left.

OK, I did the first wave of testing, and committed few little changes as commit 3989ca2 in gtk-builder branch.

What I found (note that not all of this is related to glade => ui change, it's just that I noticed it while checking UI files in action):
a) edit->plugins is showing configure options in windows, not on the config tab
b) shared memo not able to choose organizer
c) new shared memo cannot change organizer
d) assigned task doesn't show organizer
e) opening event editors shows on the console (also related to organizers)
   gtk_entry_set_text: assertion `text != NULL' failed
f) calendar/gui/dialogs/e-delegate-dialog.* doesn't seem to be used
g) e-itip-control.ui unused too
h) Contacts->view->currect view->define views->edit does nothing (when chose a
   newly created view)
i) Mail->view->current vide->save as, crashed evolution when called without
   any folder selected (it is failing silently now, though the action should
   be disabled)
j) Calendar->toolbar->Go To claims "invalid cast from `GnomeCalendar' to
   `GtkWindow'", seems the gcal isn't in the window or something
k) Edit->preferences->mail accounts->edit imap account, change type to
   groupwise will bring the proxy window. changing back to imap will not add
   the IMAP headers tab back.
l) Edit->preferences->mail accounts->Add, Identity page contains some strange
   combo under organization
m) default junk plugin combo is visible, but not filled (maybe already fixed
   in master, as there was recently a bug fix committed about the same place)

Created commit e061953 in gtk-builder for a).

Created commit 18b000e in gtk-builder for b),c),d),e)

All these were about GtkComboBoxEntry widget without having set text-column. It doesn't work in .ui file as a property, it's claiming that the model is not set yet, even it is defined in properties before this one. So setting it in the code makes it work pretty well. The same problem were on couple other places, thus I changed it there too. The error shown was also in a follow up flag dialog for mails.

Hmm, that should probably be reported as a GTK+ bug.  If both GtkComboBoxEntry and GtkListStore are buildable, there's no reason you shouldn't be able to fully wire it up in the XML file.

I haven't had a chance to follow up on this myself yet.  Are there any other outstanding issues or do you think the gtk-builder branch is ready to merge?  (It doesn't have to be perfect prior to merging.)

ad f), g) - unrelated to glade, let's play with it any time later
ad h) - also 2.28 does that, skipping it for now
ad i) - hrm, I can disable the action in mail_shell_view_update_actions
      but I can still select any other view for the no-folder, which makes the
      change slightly unusable. Any idea on this?

ad j) - fixed - the GnomeCalendar is not packed, thus passing in a parent too
ad l) - fixed - the signature combo, hiding it now
ad m) - fixed - no cell renderer set there

Created commit a0c0bb0 in gtk-builder for j),l),m)

Thus only k) lefts, plus decisions for few named above in this comment.

It would be nice to get rid of k) before, and then merge (preferable by one big commit created in master based on commits in gtk-builder branch, as I did some changes which I do not want to loose on master and I know it collides (in mail config was added a widget between time formats in Headers).

Sure, I'll pull your commits from the remote gtk-builder branch, rebase my private gtk-builder to the HEAD of master and squash my private branch down to one big commit before merging.  Then I'll delete the remote gtk-builder branch.

Branch management in git rocks.  :)

Branch merged to master for Evolution 2.29.3 in:
http://git.gnome.org/cgit/evolution/commit/?id=054c0881696a85f537e93b4950a28f505a3dc0f7

The k) issue was just another stray window in groupwise-features.  Easy fix.

Merging just -after- a release should give us enough time to catch any missed issues before the next one.

I fixed POTFILES.in/skip:
http://git.gnome.org/cgit/evolution/commit/?id=a264e68d8fca49c34d4fe2a2c97e63c28e8e45de

And I created commit 7ffc090 in evo master with dropped plugins/exchange-operations files.

There's still two includes in master:
./plugins/attachment-reminder/attachment-reminder.c:#include <glade/glade-xml.h>
./calendar/gui/print.c:#include <glade/glade-xml.h>

Is that by purpose? I don't consider this fixed yet. :-)

Go away, libglade.
http://git.gnome.org/cgit/evolution/commit/?id=d63b187d17dbca3563c7b619aac3ec3f6fe26a2a

Matthew, in your commit 054c0881, it seems some chars were lost, at least in the filter/filter.glade -> filter/filter.ui transition.

- <property name="label" translatable="yes">The message's date will be compared against
-the current time when filtering occurs.</property>
+ <property name="label" translatable="yes">The message's date will be compared against
+current time when filtering occurs.</property>

- <property name="label" translatable="yes">The message's date will be compared against
-12:00am of the date specified.</property>+ <property name="label" translatable="yes">The message's date will be compared against
+0am of the date specified.</property>

- <property name="label" translatable="yes">The message's date will be compared against
-a time relative to when filtering occurs.</property>
+ <property name="label" translatable="yes">The message's date will be compared against
+me relative to when filtering occurs.</property>

I detected a similar problem in:
/plugins/imap-features/imap-headers.ui
/mail/mail-config.ui
/mail/mail-dialogs.ui

Fixed filter.ui in:
http://git.gnome.org/cgit/evolution/commit/?id=450bd6255c7e6448070918a5a135890f83b4ca5f

I think I know how that happened.  The old libglade files had some unnecessary top-level windows that Evolution wasn't using, and I had to delete them so the widgets in those windows that we -do- use would not already be parented when they were loaded.  Given Glade's propensity to delete widgets it doesn't understand, I hand-edited the files.  That involved a block selection and deletion of the first few columns to fix indentation.  The possibility of wrapped text didn't occur to me.

Someone else reported issues in the other files you mentioned in bug #602625, so I'll fix the other (hopefully remaining) typos under that bug and close this as FIXED.