Targeting Gnome as a platform

Not all of my programming output is in the form of Gui applications, but that category makes up a not insignificant portion of what I am generally working on at any given time. It's something that I enjoy greatly because what you are working on is immediately visible to the user.

I've long since settled on Gtk+ as my toolkit of choice. There are tradeoffs involved in such a choice, but I'm going to lay out my reasons for preferring Gtk+ before moving on to iterating why I am going to be targeting Gnome more specifically as a platform going forward.

First off, I am not particularly interested in platforms other than Linux or BSD. There is no particular reason for me to care about whether my applications will run on MacOS or Windows, so I don't generally bother trying to ensure that they will. I'm equally ambivalent about Android. I would love to develop for mobile at some point in the future, but only in the context of running Linux on a phone or tablet.

This leaves the two largest contenders as Gtk+ or QT. I think that QT is a great toolkit in most ways and have explored using it via Python, but on that note I'll say that the biggest reason why I don't use QT is that it is written in C++. It's not actually about the fact that it's C++ really though, it's that QT only really supports programming for it in C++ and Python. I consider that a deal breaker. I'll concede that C++ has come a long way from what it used to be. However, Gtk+ has enough language bindings at this point as to be effectively language-agnostic. In many cases code written in other languages using Gtk+ is completely idiomatic for that language and you would never know that the underlying toolkit was written in a different language. In some cases you might see some friction between the language and the object oriented style of Gtk+, such as when using the Rust bindings, but it's generally not a bad experience overall and at least you have the option.

Why not continue using Gtk+ independently of Gnome?

Up until shortly after starting Vapad, all of my projects using Gtk+ were written is a way that was very desktop agnostic. There are a number of desktops for Linux that use Gtk+ other than Gnome actually, although many of the newer ones are arguably Gnome under the hood but with a lot of user facing changes to provide a different UI and UX. At this point as I write this I am using XFCE, which is the holdout in that while it uses Gtk+, it maintains a separate stack including it's own WindowManager, Compositor, Session Manager and Settings. I love XFCE, but I'm worried about it's future viability. Let's explore that tangent for a moment.

XFCE - it aint' dead yet, but...

Now, I'm not saying that XFCE is in danger of any imminent demise. Nothing of the sort. It's going to be around for years to come. No, what I'm saying is that without any sort of massive course alteration it's going to die a slow death and fae into obscurity. Why would I say that?

• The project has a very small number of contributors.
• They didn't finish porting to Gtk3 until Gtk4 was already out.
• There are no concrete plans to move to Wayland, and X11 is all but unmaintained.
• Even if X11 limps along for a couple of decades, at some point Gtk+ will likely stop supporting it. In fact this was already suggested as a possibility for Gtk5, see here.

What does Gnome give us?

I don't want to focus on the negative. The truth is, there's a lot to be gained as a programmer for buying into the Gnome stack. The positives are actually what sways me, because I could actually decide to help with some of the things I've mentioned previously if that's where I chose to focus my effort.

Let me start with settings and program state. Providing persistent program state and configuration is something that I've largely homebrewed in the past. This has lead to a lot of duplicated effort. It also makes the programs larger, in particular when pulling in more dependencies in Rust, for instance, to deal with writing out a config and reading it back in. But it turns out that these things are solved problems if one uses GSettings and GSchemas. Now, the sort of things that can be saved as settings are necessarily limited to a lowest common denominator of strings, booleans and various numerical types. You can't leverage the rich type system of your favorite modern programming language directly, although you might still do so by providing some translation. In exchange, you don't have to manually code in serializing and deserializing a config, and you can save widget states and have your program open up to the same state that it was in when last it was closed.

But that's only scratching the surface. I haven't talked about LibAdwaita yet.

LibadWaita - it's more than just a theme

LibAdwaita is quite misunderstood. It's also been very badly covered in the tech news sector, with a quite large number of journalists writing entire pieces on what it is and isn't in spite of obviously not understanding those concepts themselves.

The Adwaita theme is part of the library of course. You have to buy in to Gnome's blessed light and dark themes in order to use it. But in exchange you get a library which builds on top of Gtk+ with some really useful widgets and makes the job of building a polished application quite a bit easier. The results are likely to also be a lot more polished than if you roll our own. They'll certainly fit in better with Gnome, and that's kind of the point.

With Vapad, what sold me was the AdwToastOverlay. This widget provides a means to send user-facing notifications (toasts) within the application window itself. The resulting messages are a vast improvement over an old style message dialog. Rather than being a separate window, the toasts are part of the application window. They do not grab focus, they auto timeout, and don't stop the flow of work. I'm using them in Vapad to provide feedback that the current file has been saved, among other things.

After exploring Toasts, I started looking at what else the library had to offer. If one substitutes the AdwHeaderBar for a GtkHeaderBar then a separate AwdWindowTitle widget can be used for the window title. This widget gives a nice double row title with the main title being in Bold and a separate subtitle in a smaller font. In Vapad I'm using the main title to show the application name and current file's basename, with the folder in which said file resides being displayed as the subtitle. It's a nive look, and gives the user exactly the context that they need at a glance.

I also settled on using an AdwSplitButton for the program's Open button. This is a design pattern that has been in constant use for a long time. Basically it's a normal button with a menu button linked to it displaying a downward arrow. If you click the right hand side (with the arrow) you get a menu. One could roll their own pretty easily by sticking a button and a menubutton in a box and giving it the linked css class, but the library gives it to you for free, with a nice API and a consistent look across applications.

There's quite a bit more that I haven't explored yet. The AdwLeaflet looks cool. It gives you a layout that adapts between a box and a stack depending on how much space it's given. That's incredibly useful. The blackbox terminal emulator uses an AdwViewStack and an AdwViewSwitcher to create a tabbed interface with the tabs in the headerbar, which is something that you cannot do with a GtkNotebook. The Carousel widget would be a great match for a music player, where it could be used to scroll through album covers. I haven't finished exploring yet, but I think my point comes across. There's more to Adwaita than just Gnome's default and only blessed styles.

The first of my programs that I plan to move over is going to be Gfret. I already have work underway in the next branch on Codeberg. As of now the main window is ported and you can play around with the image preview but not save files, open templates or change settings. It's a WIP as it's going to be a fairly extensive rewrite. After that, I intend to get back to OxTerm. I'm still waiting on a few niceties to land in the Gtk4 port of Vte before I even consider doing any kind of release, so there's plenty of time. After that, I'll tackle Eva, with an eye towards simplifying wherever possible. Eva, being a browser, is necessarily much more complex than most of my other programs. There are quite a lot of moving parts. So it's going to take some time and a fair bit of rewriting to integrate it into the Gnome ecosystem, but I have a lot of ideas now for how to implement things more cleanly that I was struggling with originally.