GNOME Bugzilla – Bug 588945
Don't use gtk-builder-convert at compile time
Last modified: 2012-12-16 22:11:24 UTC
Glade-3 now fully support .ui files no need to keep .glade files anymore Patch coming up
Created attachment 138662 [details] [review] Remove glade files
Can you attach a diff between the gtk-builder-converted files, and these new glade-3-saved files? It should be trivial, ie. only removing lines for property values that are at their default. And in the next iteration, if you load + save these new .ui files in glade-3 again, the diff should be empty. Is that the case?
I've used the gtk-builder-converted files in this patch. So the diff is zero. Probably easiest applying this patch and afterwards replacing it with the .ui file that Mathias attached in bug 588732. OK to commit? I can also commit the file that Mathias provides
Well, if these files are to be added to git, they should be in a form so that loading + saving them again in glade-3 produces a zero diff. That means doing this load+save once, reviewing the diff to the gtk-builder-convert generated originals, and also veryfing that another load+save cycle doesn't introduce any diff. And testing that the converted files do in fact work (esp. the profile editor had problems.)
Created attachment 138765 [details] [review] Patch showing differences between gtk-builder-converted files and glade-3 ui generated files
Created attachment 138766 [details] [review] Remove glade files by loading saving as builder file in glade-3 OK I misunderstood you in the beginning. Here's a patch where loading and saving of .ui files in glade-3 will not generate a diff
You need to remove $(builder_DATA) from CLEANFILES as well. (No need to attach an updated patch just for this.) Setting target to 2-28, but I need to double-check this patch before I can give ok-to-commit. (I don't trust glade-3 one bit.)
(In reply to comment #7) > You need to remove $(builder_DATA) from CLEANFILES as well. (No need to attach > an updated patch just for this.) Sorry missed that one. > Setting target to 2-28, but I need to double-check this patch before I can give > ok-to-commit. (I don't trust glade-3 one bit.) > glade-3 seems to work for most people. Anyway I hope you have time to review this patch before 2.28
I also had to fix po/POTFILES.in. Loading + saving the files in latest glade-3 doesn't introduce any diff, that's good. However, one effectively cannot actually edit the files in glade-3, since they're _displayed_ totally broken (some problem with vboxes being displayed horizontally?) That makes it impossible to commit this patch at this time.
Created attachment 140653 [details] [review] fixed patch
See also bug #584029 (g-c-c) and how it has been workarounded: http://git.gnome.org/cgit/gnome-control-center/commit/?id=674deec47195d98c88acd9208aa986401a752e8a
I hope we can fix this ASAP, 'cause gtk-builder-convert was removed from gtk+-3, forcing gtk+-2 as a build dependence to gnome-terminal. Is it OK to mark as 3.0 blocker? PS bug #588732 should be a duplicate.
(In reply to comment #12) > I hope we can fix this ASAP, 'cause gtk-builder-convert was removed from > gtk+-3, forcing gtk+-2 as a build dependence to gnome-terminal. That's how the gtk+ devs wanted it, so that's how it is. > Is it OK to mark as 3.0 blocker? No. That would be useless, since I'm not going to do this for 3.0.
@Christian there is a conflict of interests between you and gtk devs? in my opinion the drop of gtk-builder-convert should signal the other developers to stop using gtk-builder-convert and comply to the "new" stuff. is kinda ironical to have gtk2 as build dependency when building a gtk3 app.
Well, chpe has his preferences, and we have ours. Not a blocker in any way, as far as I'm concerned.
*** Bug 652738 has been marked as a duplicate of this bug. ***
Created attachment 227246 [details] [review] Update In case anyone's interested, I updated that patch against gnome-terminal 3.6.1. It doesn't apply on master and the maintainer's lack of interests on this matter doesn't really motivate me to work it. Hopefully somebody finds this useful.
Hi Lionel, I'm working on this bug, trying to make your patch work in master. I will try to send an updated patch this weekend but, as you've said, is the maintainer who should approve it. But since this is a GNOME Goal (and also removing markup from strings, see bug #683653) maybe with a working patch we can close this two bugs. If I have any question/problem, I'll post here a comment. Many thanks for your work on this bug... hope we can finish it!
Created attachment 227885 [details] [review] Switch to GtkBuilder Based on the patch sent by Lionel, this patch seems to work properly (at least, there are no erros when compiling the module). This patch drops all the src/*.glade files, and creates new UI files. The new UI files have also been added to po/POTFILES.in file. Please test it and tell me If I should fix anything. Thanks!
I've just tested with latest glade3, and it STILL cannot show the profile-preferences.ui file correctly.
I've tested it and I can open the file and seems to be ok. Where is the problem and how could I fix it? If this is the only file with errors, maybe you could help me fo fix it. I'm not very sure about how to do it.
Created attachment 228791 [details] [review] Patch updated Patch updated. The previous patch was wrong, since it didn't changed the src/Makefile.am and the po/POTFILES.in files. The preferences dialog is still wrong: the module compiles and runs properly but when I try to show the preferences dialogs, the program closes without any warning or message. Christian: Hope you can help me to fix it. Thanks!
The ui files in the patch are different from the gtk-builder-convert'ed files generated during build from the .glade files. How did you generate them?
My patch is based in the last one sent by Lionel Landwerlin. I took it and fixed it to make it compile and run the application. The only part is not working is the preferences dialog, and it was the part I hoped you could help me to make it work to close this bug. Applying my last patch, gnome-terminal compiles and runs fine but, when you try to show the preferences dialog (using the menu or right-clicking with the mouse), the application closes cleanly (no warnings, errors, etc). Also, gdb doesn't show any warning or error message, but I've not been able to identify where/why it fails. I've also tried to convert the preferences dialog using Glade, but not using the gtk-builder-convert script: I created a new project, copied the notebook widget from the original dialog and pasted it in the new project. Saving this new file as an .ui file, generated a completely different file, but it still didn't work.
The diff between the autogenerated profile-preferences.ui file and the one from the patch shows - obvious additions (new properties); those are fine mostly - invalid additions: that's stuff that was removed from g-t master already (background prefs, 'always show menu bar'); these need to be re-removed from the patch - nonobvious changes; glade / whatever edited these files made a mess, so I can't really tell what that stuff is doing, but it's likely the cause of the bug
And how could I/we fix it?
Christian: any idea about how to fix it?
I don't think the current patch can be salvaged... probably best to start from scratch: 0) create branch, commit the autoconverted .ui files 1) for each .glade file: use the old gtk2 glade3 (glade-3 command on fedora) to load the .glade file, save as .ui. use a text editor or meld to port over the useful bits from the glade-3-converted .ui files over to the autoconverted .ui files; and commit the result. That should give a working ui files that a) work in g-t; b) work in glade (new, gtk3) (at least, as good as glade works at all, which isn't very well), and c) has useful and auditable git history.
I disagree... all the UI files, except the preferences dialog, are working, so starting from scracth just would duplicate work. As it is the only broken file, we should try to fix it. Maybe Glade maintainers could help us to fix it. The other files are working properly so, IMHO, they shouldn't be modified.
*** Bug 588732 has been marked as a duplicate of this bug. ***