In defense of Glade
Recently, I stumbled upon a blog post from a developer involved in various GNOME apps in which he strongly recommends to not use Glade for designing Gtk-based user interfaces. Since I use Glade extensively for Horizon EDA this post felt relevant to me. Let me give you some background on my experience with Gtk and Glade before presenting my stance on this subject.
A long time ago, back in the heyday of GNOME 2, I was starting to get the hang of python and wanted to implement graphical user interfaces. Not being satisfied with python’s builtin Tk, primarily due to its ugly looks, I started to explore other libraries. Most notably wxWidgets, Gtk and Qt.
Out of these three, I picked Gtk since its API made sense to me and Glade made developing UIs much more approachable. I also played with UI designers for Qt and wxWidgets, but Glade was the least intimidating one. Since then, Gtk and Glade were inseparable for me.
When I started Horizon EDA, Gtk and Glade were the obvious choice for me as I was familiar with them. Many of the more complex parts of the UI such as the part editor are implemented partly using Glade. The good thing about Gtk’s GtkBuilder (the XML format Glade outputs) is that it isn’t all-or-nothing. It’s easily possible to mix-and-match widgets created in code with widgets defined in a GtkBuilder XML file. This greatly helps to work around some of Glade’s shortcomings, such as making it difficult to use custom widgets.
While the arguments brought forward in the linked post are true and I
don’t contend that Glade isn’t without its downsides, I wholeheartedly disagree
with the author’s conclusion that these points make Glade more harmful
than useful. From all of the points mentioned in the blog post, I’ve
only encountered the second-last point, namely Glade sometimes
rearranging objects in the XML file, making diffs less useful. The
double borders caused by
GtkViewports are easily suppressed by
turning off the viewport’s border. I also never touch the XML files
generated by Glade with a text editor, so if a feature isn’t supported
by Glade, I’ll work around it in code rather than manually patching the
The author also completely dismisses the value Glade provides by directly manipulating the widgets rather than editing an XML file and only getting visual feedback after another compilation cycle. From my perspective this more than offsets the shortcomings listed in the post.
However, if you’re developing a core GNOME app and want or need to use the latest Gtk best practices, I can see why Glade might not be for you. If you happen to develop a random Gtk-based application like I do, there’s nothing wrong with using Glade.