Revisiting Vapad

2023-05-18

Vapad is a little text editor that I started a year ago (or thereabouts) just in order to try out programming in Vala. It's intentionally a pretty simple little editor, but exposes a lot of the underlying functionality that you get for free just by including GtkSourceView such as syntax highlighting, smart indentation, and even vi mode. Being a Gtk+ app it's most useful on Linux or BSD.

At the time I last worked on it, I was beginning a transition to use some of the more recent Adwaita widgets with an idea towards eventually having a release capable of running both on desktop and devices like the Pinephone. It's got a ways to go yet, and I had to brush up a bit on Vala again. So my first order of business was dealing with some compiler warnings that have crept in while I was away due to deprecations in Gtk+. Once that is under control I'll dive back into features.

Gtk+ deprecations affecting Vapad

GtkFileChooserNative - replaced by the new async GtkFileDialog

GtkFontChooserDialog - replaced by the new async GtkFontDialog

GtkDialog - no replacement

GtkStyleContext - some functionality moved into GtkWidget, for the rest there is no replacement

GtkEntryCompletion - replacement has not landed

GtkListStore - used by GtkEntryCompletion so waiting on it's replacement

So far I've ported one of three instances of the file chooser over to the new async dialogs. It was a bit of a chore, as there are no provided examples and the Vala interface doesn't match the C interface function for function. I had to ask on the Gnome discourse forum, where I did get a prompt answer, then take what information I got in that answer and figure out how to apply the docs that I was pointed to for the widgets that I was using. As aggrevating as it potentially is when the answer that you get just points you at another doc which doesn't address specifically what you're working on, it did result in my understanding the Vala async interface better so I was better able to cope with the next challenge, which was the font chooser. Indeed, while it took a couple hours to figure out the file chooser I probably took fifteen minutes this morning to port the font chooser.

The only instance I currently have of a generic GtkDialog is a little yes/no message dialog which pops up when you attempt to close any tabs with unsaved work, or to quit the program with any unsaved tabs. There are a couple of different ways I could deal with this. I could just use a GtkWindow, and make it modal for the application window, and thus replicate the interface that already exists from a user standpoint. The other option would be to present that yes/no option as an overlay on the application window itself. As I conveniently already have an overlay in the form of an AdwToastOverlay, and that widget inherits from GtkOverlay, the bones are already there to do just this. I'm leaning towards that option.

As for the StyleContext, I'm not entirely sure how to accomplish what I'm doing yet. I'm pretty sure there's a way to tweak thins so that I'm not using StyleContext directly but I just haven't researched it yet.

The completion issues (and to a lesser extent the style context issue) highlight one of the often heard complaints about the Gnome developer community. In the case of the StyleContext object, they're literally exposing less functionality in the libraries, thus making it harder to customize applications and steering developers towards only using the one blessed theming option. Only in my case, I'm only using StyleContext to set the editor font, which is something that pretty much any graphical text editor ought to be able to do.

In the case of the completions, they deprecated a fairly well used interface before even starting work on it's replacement. I've asked about this already. I got a reply that stated what the intended replacement interface was going to be based on but no timeline for when it's going to land (or even be started) other than "before Gtk+-5.0". This leaves developers in a bad place IMO. I would love nothing more than to get to work on porting over to the new interface now, since the old one is already throwing compiler warnings, but that new interface doesn't exist in any form beyond a vague plan.

Vala is still a joy

Forgetting the negativity for a moment, I still find Vala to be an absolute joy to work with. In the context of Gtk+ application development, it is by far the best way I've encountered to get an application off the ground running. It's like Gtk+ was made with Vala in mind from the start, even though it's written in C. The only other language that *might* provide a little less friction to newcomers in this context is Python using PyGtk, but then you're out of the world of compiled code and using an interpretor. This is likely fine if your program is just a frontend for something else, but you'll quickly notice the slowdown if you have a lot of business logic written in Python.

Interestingly, I'm not even a big fan of Object Oriented programming to begin with, but it seems to make sense for Gui applications. At the very least, working in a language which was designed from the ground up for GLib/GObject and Gtk+ provides a really low friction way to get into it and write some native Gui apps for *nix.

Tags for this page

All content for this site is licensed as CC BY-SA.

Finger

Contact