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.
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.
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.
> ...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?
In the earlier days, both Qt and gtk quickly jumped on the theme train, where you could customize the looks of widgets heavily, and IIRC FLTK never caught up there. I think the default L&F can compete with default gtk1/2 or Motif-ish Qt, but you couldn't go up from there or try to have a common look & feel between toolkits.
These days, that has gone one step further. Where a lot of people consider anything with "old-school" widgets to be ugly and outdated, and a more web-like cards/list-view based approach with highly customized and animated UI elements.
Qt with its QtQuick/QML parts seems quite competitive there, not sure how good Fltk 1.4 is here.
(Just repeating the way I see the "state of the art" here, I personally don't like that "proper" GUIs are now retrocomputing)
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.
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.
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.
WxWidgets uses native widgets, for better (e.g. automation, screen readers) and for worse (weird platform differences, flickering, lots of “common ground” limitations).
FLTK draws the controls on its own - for the better (incredibly fast, consistent across platforms, flicker free since 1998, super easy to implement new widgets) and for the worse (bad support for complex text layout in Asian and bidi languages, no support for accessibility)
I would say it’s the wrong tool for a mass-market product or if you need non European language support.
It’s the perfect tool for internal projects that only require European/English languages.
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.
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.
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.
https://en.wikipedia.org/wiki/Nuke_(software)
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).
FLTK history explicitly mentions rewriting from libGL heavy code to pure X11 because of the differences in how useful GL was outside Xsgi[1]
[1] a quick example is how IRIX vector icons are actually serialised IRIX GL display lists
More about FLTK and Nuke: https://dl.acm.org/cms/attachment/885732b3-c342-45f4-9845-7c...
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?
> GUIs made in FLTK are visually ugly.
In the earlier days, both Qt and gtk quickly jumped on the theme train, where you could customize the looks of widgets heavily, and IIRC FLTK never caught up there. I think the default L&F can compete with default gtk1/2 or Motif-ish Qt, but you couldn't go up from there or try to have a common look & feel between toolkits.
These days, that has gone one step further. Where a lot of people consider anything with "old-school" widgets to be ugly and outdated, and a more web-like cards/list-view based approach with highly customized and animated UI elements.
Qt with its QtQuick/QML parts seems quite competitive there, not sure how good Fltk 1.4 is here.
(Just repeating the way I see the "state of the art" here, I personally don't like that "proper" GUIs are now retrocomputing)
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.
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.
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.
https://xdiskusage.sourceforge.net/
Congratulations! As a side note, there is a lightweight X Window Manager based on FLTK - FLWM (https://en.wikipedia.org/wiki/FLWM)
The FLTK use case seems to overlap heavily with wxWidgets. Are there reasons to choose one over the other?
WxWidgets uses native widgets, for better (e.g. automation, screen readers) and for worse (weird platform differences, flickering, lots of “common ground” limitations).
FLTK draws the controls on its own - for the better (incredibly fast, consistent across platforms, flicker free since 1998, super easy to implement new widgets) and for the worse (bad support for complex text layout in Asian and bidi languages, no support for accessibility)
I would say it’s the wrong tool for a mass-market product or if you need non European language support.
It’s the perfect tool for internal projects that only require European/English languages.
In between those, depend on the details.
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...
The mainline Dillo it's getting UTF8 improved support thanks to that release.
Happy to see that Dillo[0] is active[1] somewhat.
0. https://dillo-browser.github.io/
1. https://github.com/dillo-browser/dillo/commits/master/
Wayland finally!
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.
It doesn't depend on OpenGL, does it?
OpenGL is an optional dependency.
See: <https://packages.gentoo.org/packages/x11-libs/fltk> and <https://github.com/fltk/fltk/blob/6df2219aa0e56d9632824c94a3...>
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....