If you are starting out with GTK development, you may have heard of a tool called Glade. Glade is a UI designer application for GTK projects, that allows you to create, modify, and preview UI files before writing code. In that sense, Glade is a very useful tool for GTK apps.
With that said, I must implore that you do not use Glade.
Why? Glade was built for it’s own format, before the advent of
GtkBuilder. It does not know certain properties, does not know
of certain features, and does not know modern GTK practices.
Instead of ignoring what it does not know, it aggressively “corrects” it. Glade will re-write your UI files to its whims,
including but not limited to:
Removing property bindings
Removing unknown properties
Adding child properties to GtkBox children everywhere
These are gone in GTK 4, which adds extra work to the porting process
Adding explicit GtkViewports that cause a double-border
Forcing minimum width and height on GtkListBoxRows
Re-arranging objects within the UI file
Changing the format of all properties in an edited UI file
This makes Glade harmful in different ways. Your UI files will be bloated, due to Glade adding placeholders, child properties,
and extra widgets where they aren’t needed. When you make a
contribution to an app, you may be asked to re-do it by hand
because Glade made unnecessary changes. When porting to GTK 4 you
will need to do more work, as Glade doesn’t know to avoid
deprecated widgets, properties, and child properties.
All of these elements combine to make Glade more harmful than helpful. So please, do not use Glade. If you are working with UI
files write them by hand. An editor with code folding and syntax
highlighting can be very helpful. If you need to mock something
up, you can try sketching on a piece of paper or using our mockup resources. Whatever you choose, don’t use Glade.
Over the past year or so I have been a regular contributor to Fractal, a Matrix chat client for GNOME. My contributions have allowed me to take on a bigger role in the GNOME community, including the maintainership of a few apps. I am pleased to announce that over the next week I will be working to make Fractal’s UI adaptive for the Librem 5’s launch. This contract began last week, and I already have some results to show off.
The Main View
Fractal has used a split window pattern since it’s inception. With HdyLeaflet apps that use this pattern can adapt their size to fit different widths. Once !363 is merged, Fractal will use HdyLeaflet to adapt it’s main view.
In combination with HdyLeaflet, HdyDialog allows us to have dialogs that grow to the full size of the window at smaller sizes. I changed most of the instances of GtkDialog into HdyDialog and made sure each one would fit into the Librem 5’s constraints.
The Room Details
The room details view was something started a long while ago by Julian Sparber, made before HdyColumn was a thing. HdyColumn allows widgets to expand up to a certain width, while still being able to size appropriately on smaller screens.
Our on-boarding process is in need of a redesign in general, so while redesigning it we can design for mobile as well.
Mapping Clicks To Touches
Currently we have a context menu that is accessed by right clicking on a message. This will need to work for long press on the phone, since there’s no way to right click on a touchscreen.
The Image Viewer
The controls of the Image Viewer’s headerbar are too large for it to shrink to the Librem 5’s constraints. We’ll need to make sure these controls are re-arranged in order to allow the viewer to fit correctly.
The Room Directory
The room directory is another view with controls that will need to adapt to small sizes. It has a searchbar, a back button, the items in the list don’t shrink enough for the rest of the window.
Overall, I’m very excited that Purism accepted my proposal and that I get to work on this. I have been looking forward to the day where I can run Fractal on my phone, and I’m glad to be bringing that closer.