Interesting bit of lore: FLTK was developed as a GUI toolkit to power Nuke, which at the time was the in-house high-end VFX compositing tool at Digital Domain. Nuke was then sold to The Foundry and its UI rewritten in Qt, but the legacy (in the form of FLTK) continues.
More about FLTK and Nuke: https://dl.acm.org/cms/attachment/885732b3-c342-45f4-9845-7c...
I thought I remember reading that there is some relation (or inspiration) from an older X11 toolkit called xforms. Which might also be of interest to someone.
I've been redoing some old projects in FTLK recently so this sparked my interest. And I just like delving into the history of things.
If I remember correctly, both FLTK and XForms have a commmon "ancestor" in the Forms library for SGI (pre-OpenGL days).
For those unfamiliar, FLTK is a cross-platform widget library in C++, with bindings to many other languages available. It's vaguely similar to something like Qt, but far simpler and far more developer-friendly. It is excellent; strongly recommended to all, for everything.
If it’s “far simpler, more developer friendly and recommend for everything”, why are there so many QT applications- and so few FLTK applications?
> ...why are there so many QT applications- and so few FLTK applications?
As someone who used to work with FLTK and loved the hell out of it: compared to QT, GUIs made in FLTK are visually ugly.
FLTK makes totally reasonable GUIs that folks can easily understand and that behave in sane ways. It "just" doesn't look "modern" and hasn't for decades... if it ever did.
I prefer how FLTK looks, but I guess the average joe doesn't?
The default FLTK look and feel might be discouraging, but there are some really great native themes shipped for the Rust bindings: https://github.com/fltk-rs/fltk-theme?tab=readme-ov-file#wid...
All of those look broken, especially the "classic" one but all of them have issues. They look like a bitmap-based theme engine tried to do arbitrary scaling of bitmaps without even bilinear filtering (which, don't get me wrong, would also look bad - but this looks even worse).
Except it seems that they are defined in code[0], calling FLTK functions (these draw_xxx functions are wrappers/bindings for Fl_xxx functions). I'm not sure where exactly things break, the code (at least the linked one) seems mostly straightforward. Does FLTK try to scale draw call coordinates? While scaling coordinates is helpful in general, for low level drawing like implementing themes, it should be disabled and have the themes handle scaling themselves in a way that doesn't look like someone applied widths and heights randomly.
I wonder if this is an FLTK limitation or the theme author not paying much attention to details.
[0] https://github.com/fltk-rs/fltk-theme/blob/main/src/widget_t...
The default look seems pretty efficient and informative, fairly Windows 95ish.
You know, back when controls were demarcated as controls...
Why is the dot in the radio button not centered?
This might be rounding error.
Those themes look worse than the default ones. We really need aesthetic design sense in the open source community.
I'll take a UI that works over one that's pretty any day. (They are almost never both)
I'm a lurker here, never posted before :) This post brought back lots of memories. I wrote many small applications with FLTK; my favorite one is https://www.muquit.com/muquit/software/mbasecalc/mbasecalc.h.... I still use it today.
xdiskusage is an FLTK program I use regularly. It's still one of my favorite ways to analyze disk usage. A nice feature is that it can take a du output file so it's easy use it with filtered du outputs, du runs from other machines or du-like output produced by other means.
I used Ruby/FLTK on a CD software installation script project almost exactly 20 years ago. Haven't used it since, but it worked out pretty well for that particular project given the small size and simplicity.
Congratulations! As a side note, there is a lightweight X Window Manager based on FLTK - FLWM (https://en.wikipedia.org/wiki/FLWM)
Fltkhs [1] was the best ever experience I've had while doing small/auxiliary GUI utilities. Now using NWG [2] for that (UI forms examples [3]) and it is so much less elegant and so much more verbose than Fltkhs. Resulting lean EXEs without any bundled runtime are nice though.
[1] https://github.com/deech/fltkhs
[2] https://github.com/gabdube/native-windows-gui
[3] https://github.com/wiltondb/wiltondb/wiki/WiltonDB-Data-Tran...
It doesn't depend on OpenGL, does it?
The mainline Dillo it's getting UTF8 improved support thanks to that release.
Happy to see that Dillo[0] is active[1] somewhat.
This is fantastic. FLTK is great software and a very nice library to know. Now having wayland support and high dpi support, it will what people need in a more modern GUI library.
With previous versions you could get the pdf for all your documentation and start with a 100KB completely static binary that would show a window and buttons. The source is pretty clear so making your own components or modifying existing ones is straight forward and it really is lightweight and FAST.
It also has network stuff and jpg/png and audio libraries so checks off a few more potential dependencies. It has threading too, but that seems like less of a modern issue.
If someone was delivering software I would love it to use FLTK and be a single fast static binary. That's the kind of stuff that isn't a constant pain and can just work so you can move on to other problems.
the website seems to have been receiving the hug of death from hackernews :(
snapshot from the wayback machine:
https://web.archive.org/web/20241118160735/https://www.fltk....