Modern GUI toolkits use declarative languages to construct user-interface elements/entities and manipulate their behavior from programming languages. This way, applications can have a clear separation of user-interface layouts and business logic, enabling popular design patterns for software engineering such as MVC, MVP, etc…
GTK is quite powerful in this aspect. With composite widget templates our developer story has become even more compelling. It has empowered our designers to contribute directly to the code base, eased our newcomers learning curve, and allowed for the composition of widgets to produce even more complex ones.
Our application developers tend to architect their application user interface with two different approaches: using Glade or writing UI files manually in a plaintext editor.
Being a WYSIWYG interface editor makes it a valuable entry point specifically for those not used to GTK application development. Composing interfaces by dragging-and-dropping widgets can be very handy, at least in theory.
Many experienced GTK application developers will advise you not to use Glade nowadays, for various reasons, including:
- Lack of support for modern GTK widgets and custom widgets
- Cumbersome changes in UI files, difficulting versioning operations such as git diff/blame
- Lack of active maintainership
Widget packing is key to the way GTK UIs are built. By writing UI files manually I get full control of which widgets are used by my application and how their properties are set. I also get to make small changes in existing interfaces without generating unnecessary verbose results in the backing UI file.
Unfortunately, it can be considered a bit unpleasant having to write in such a verbose language.
<object class="GtkButton" id="my-button"> <property name="visible">True</property> <child> <object class="GtkImage"> <property name="visible">True</property> <property name="icon-name">audio-volume-high</property> </object> </child> </object>
The example above shows that it takes about 10 lines to build a simple button with an image on it.
Also, the overuse of XML attributes instead of nodes makes you write “object class”, “property name” for every node.
The case for UI declarative languages
Writing interfaces by hand doesn’t need to be painful. Various thriving GUI frameworks don’t have WYSIWYG editors but have compelling declarative languages that make writing UI layouts a piece-of-cake.
After discussing this on Twitter, I decided to raise this discussion here, where we could evaluate the pros-and-cons of this proposal.
I understand markup parsers can be difficult to implement, and that the less verbose a markup is, the more undefined behavior one could expect as result. Therefore I suggest that we also discuss intermediary steps to gradually simplify our UI. I personally think that we should still stick to XML, but work towards simplifying our language spec.
In the Twitter thread linked above, I drafted how a simplified version could potentially look like (from an app developer’s convenience POV):
<button id="my-button"> <image icon-name="audio-volume-high"/> </button>
Please, notice that this is a strawman proposal to generate discussion of its disadvantages and to provoke the generation of new and better proposals.