After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 651820 - Port the remaining static UI python code to GtkBuilder
Port the remaining static UI python code to GtkBuilder
Status: RESOLVED FIXED
Product: pitivi
Classification: Other
Component: User interface
Git
Other Linux
: Normal normal
: 0.91
Assigned To: Pitivi maintainers
Pitivi maintainers
Depends on: 651821 655086 655436 655438
Blocks: 679758
 
 
Reported: 2011-06-03 22:28 UTC by Stéphane Maniaci
Modified: 2012-10-28 18:02 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Stéphane Maniaci 2011-06-03 22:28:22 UTC
Aside from dropping the dependency on Glade (and our custom glade.py) there is room left for GtkBuilder goodness. A bunch of UI code is made into the Python source code, which is not good for several reasons:

   - Glade+GtkBuilder offer a visual way to layout and configure everyting. Less code, better UI/source separation, easier contribution, etc.
   - GtkBuilder also wraps the different enums and constants of Gtk we use in our code, like GTK_FILL or GTK_STOCK_DIALOG_WARNING and things like that. This is not accessed the same way in PyGTK and PyGObject (Gtk.AttachOptions.FILL for example). Thus, putting all that in GtkBuilder files makes it easier to port to PyGOBject (and to other languages in theory).

So once Thibault merges his GtkBuilder branch (which drops the Glade dependency), it would be nice to track every not-custom UI code in the source, and port this to a proper GtkBuilder file. This is an easy but laborious task, see the PreferencesDialog example (in the bug dependency) to see how it works.
Comment 1 Jean-François Fortin Tam 2012-10-28 18:02:50 UTC
Pretty much everything is done now, individual issues should be filed for remaining components, if any, where it would be worthwhile (ie: save a lot of code/complexity) to do so.