Graphical user interfaces with FLTK

Every programmer needs to make a graphical user interface sooner or later, but most GUI toolkits are infamously hard to use. That's how we ended up with browser-based platforms that developers love as much as users hate. (I favor Tkinter instead; it's equally good for apps and certain games.) Actually there are lots of games that use GUI toolkits; we usually think of them as distinct from apps, but the lines blur when you look at something like TuxPaint. And you know what? That's a good case study.

Common wisdom among programmers is that users will go "yuck" at non-native interfaces, and indeed people tend to complain loudly if an app stands out from the rest. On the other hand, a lot of them feel intimidated by the clinical gray GUI style that's still the default on some operating systems. They crave a little color and whimsy in their digital life. But you can't make a Gtk+ or Qt app that has rounded buttons just because, or goes beep and bop when you click: that would be gasp too whimsical!

Except, as it turns out, what everyone dislikes is poorly made user interfaces, native or not. They'd sooner use those hated browser-based apps, for all their warts. The hard part is learning why, because hardly anyone is equipped to talk about ergonomics, and design has become a dirty word synonymous to unusable artsy stuff.

Wish I could teach users to articulate their needs better, and programmers to listen. But that's a dream, so let's set our sights lower for now.

Where play meets work

I've done little in the way of games lately, and more to do with playful little tools of the sort that Nathalie Lawhead writes about all the time. Mine usually don't work out so well: VoxelDesc and Stereo Imagination went nowhere, while Tipsy Turtle was almost there but not quite. Genoa nails it, hopefully, but that remains to be seen. Point is, you can afford to experiment with one of these; not so much with somebody's word processor that they use to make a living. But for that you need the right tools.

I use Tkinter because it's readily available, familiar to me, and it works. Also it only has around one hundred classes: a reasonable amount to learn. Most competing libraries only tick one of these boxes, or none at all. But sticking to what I know isn't great either. For one thing, Tkinter limits me to one language; make that two with the underlying Tcl/Tk. And then, it has quirks. So what else is there? Eighteen months ago I wrote about paths not taken; been thinking about it ever since. Obviously XForms isn't a realistic option in 2023, but as it turns out there's a spiritual successor (in fact a cousin) that's still being developed, and rather more popular too.

FLTK is best known for its use in the Dillo web browser, but also the SmallBasic IDE. See how different they look? With FLTK you can do that. It matters when you're making software for entertainment; remember WinAMP?

(Oh look, another excellent case study in what people really like in user interfaces.)

Beauty is skin deep

Now, by default FTLK attempts to imitate the user interface of each major operating system, but these attempts look a couple decades out of date. My first instinct was to at least make toolbar buttons flat, 2020s style:

Screenshot of a bare-bones text editor with a few gray-scale icons on the toolbar and a search box to fill the empty space, showing its own source code.

Well, the library did let me try, but the results aren't going to fool anyone. So after flailing around for a while, I decided to let go and do the exact opposite, namely to lean into its own unique aesthetic:

The same text editor, now with a glossy, outset menubar and matching toolbar buttons.

That's better, except those glossy buttons beg for colorful icons, or else text labels. But there's another way to fill all that empty space:

Yet another variation on the same user interface, with the toolbar now taking up the right half of the menu bar, and a menu open, as glossy as the rest.

Turns out, menu bars in FLTK are just another widget, not an intrinsic part of the window! That can be a perfect match for split-pane user interfaces like that of OpenSCAD or QBJS. They're very popular as of late, come to think of it, as if orthodox file managers were coming back in fashion.

Are we having fun yet?

Eight hundred words in, some boring screenshots are all I have to show. Let's see what else FLTK has that sets it apart:

In the way of downsides, FLTK is written in old-school C++: its first release predates the '98 standard! (On the plus side, that might appeal to C programmers.) Layout management is unusual to say the least, and there are many other quirks, big and small. But you can tell it was thoughtfully written, not just overbuilt for the sake of it, and its flexibility is unmatched. Pretty much everything inside can be customized, extended... and understood. Give it a try.