FLTK hits 1.4, arrives speaking Wayland and with better HiDPI support

A mere 13 years since the last point release

FLTK, one of the oldest and most stable FOSS toolkits for programming GUI apps, is back with new shiny.

FLTK 1.4 was swiftly followed by a minor bugfix, version 1.4.0.1. Although the project never went away and there has been a continuous slow trickle of minor versions, it's over 13 years since the last major point release, version 1.3.0 in June 2011.

These days, it's a C++ library whose name stands for the "fast light toolkit", which is descriptive. However, the initials originally came from the fl_ prefix to functions in the Forms Library of Silicon Graphics's proprietary IRIX Unix. FLTK started out as a compatible replacement for the SGI Forms Library, as described in the project's history, which also reveals that FLTK is pronounced "full tick".

(As it happens, another FOSS GUI library also started out as a replacement for the SGI one: XForms. XForms is still around too, although more aimed at plain old C rather than C++. In another instance of an initialism being redefined, XForms was the original toolkit used for the XFCE desktop. Xfce 3 was rewritten to use Gtk instead, and since then its name is written in sentence case instead.)

The biggest change is that FLTK now has better support for greater-than-standard-definition displays:

FLTK 1.4 adds support for HighDPI displays under Linux/Unix and Windows and improves HighDPI support on macOS. The initial screen scaling factor is read from the system and application windows can be zoomed (in/out/reset) by the user with ctrl/+/-/0 shortcuts, respectively.

It's also natively able to use the Wayland display protocol under both Linux and FreeBSD.

FLTK was originally built for the Nuke visual-effects app, although since version 5 that's moved to using Qt instead. FLTK is also used in some moderately well-known FOSS apps, such as the recently-revived Dillo lightweight web browser and the FLWM window manager, as seen in the ultralightweight Tiny Core Linux.

Another tool which uses FLTK is the Equinox Desktop Environment, or EDE for short. EDE also hasn't seen an update in a similarly long time: the project was rebooted in about 2009, and this 2013 interview suggests that the long gap before the release of EDE 2.0 in 2012 was due to trying to rebuild it on FLTK 2. That effort began in 2002, but FLTK 2 never happened, although there are still mentions of it in the FLTK documentation.

Now that there's a new major release in the FLTK 1.x codebase, perhaps some more activity in related projects such as Dillo and EDE will follow.

Perhaps FLTK could even attract the attention of other desktops that have a slower, more measured development cycle. It took years of work to port Xfce from Gtk 2 to Gtk 3: The Register reported on the project's core components moving to Gtk 3 back in 2019. Just a year later, Gtk 4 débuted.

Five years after this, Xfce 4.20 is expected next month and should have preliminary Wayland support at last… but Gtk 4 remains an as-yet-uncharted future path – and maybe a step too far.

As we've noted before, the GNOME development team is, shall we say, not famed for playing nice with other desktops. Gtk 4 is intended for use with the GNOME desktop version 40 and later, and that's all. If it's useful to anyone else, great, but we see no signs that this an important objective.

Just as modern GNOME doesn't offer much room for end-user customization, Gtk 4 blocks users from customizing themes. It doesn't go out of its way to help programmers, either: for instance, the Gtk documentation on migrating from Gtk 3 to Gtk 4 says:

GtkMenu, GtkMenuBar and GtkMenuItem are gone

The docs describe menus as "heavily relying on X11-centric concepts" that "were hard to adjust to other windowing systems." (This sounds strange to us, as we seem to recall menu bars originated on the Apple Lisa and Mac, and only came to Windows and X11 later, but what do we know?) At any rate, Gtk 4 seems very far from ideal for a traditionalist environment like Xfce.

Maybe the Xfce developers could weigh up moving to FLTK instead. Perhaps one of these fancy "AI" coding assistants could be trained to help? After all, it's essentially a very big complicated search-and-replace operation. ®