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.
mhd 13 hours ago [-]
If I remember correctly, both FLTK and XForms have a commmon "ancestor" in the Forms library for SGI (pre-OpenGL days).
p_l 8 hours ago [-]
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
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.
jorvi 14 hours ago [-]
If it’s “far simpler, more developer friendly and recommend for everything”, why are there so many QT applications- and so few FLTK applications?
simoncion 13 hours ago [-]
> ...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?
mhd 13 hours ago [-]
> 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)
HelloNurse 5 hours ago [-]
FLTK remains "Fast and Light", which is how the enlightened minority who wants proper GUIs want it.
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.
Theme author here! I designed those for a few of my C++ programs years ago, back before FLTK had high-DPI support. (I wasn't involved with porting them to fltk-rs, but I'm glad FLTK for Rust has them available!)
At 100% scaling, they look they way they're supposed to.[1] But at other scales, particularly non-integer ones, their drawing code will need updating to use the new fl_override_scale()/fl_restore_scale() API.[2] (Now that 1.4.0 is officially out, I expect to get back to maintaining those programs.)
As a chemical engineer in the late 90's I used fltk to write a real-time photoresist film web inspection system. The first version in VB was too slow as the system used a laser to scan for defects in film going by at several hundred feet per minute. I was a novice C++ programmer and fltk was the only toolkit I could get my head around and came with a great UI builder (fluid). I even was able to write my own widgets. And all of this was running on a Celeron 300MHz system.
UncleOxidant 18 hours ago [-]
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.
donio 17 hours ago [-]
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.
As great as it may be, this isn't something I'd pick as it'd be unusable in this cases.
hulitu 2 hours ago [-]
> Zero accessibility =/
You should see Windows (10, 11) or Android.
Gray on gray, no scrollbars, messages using half of screen, buttons you didn't asked for ( why do i need a microfone icon when the app has no microfone permission ? )
staticlibs 17 hours ago [-]
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.
The FLTK use case seems to overlap heavily with wxWidgets. Are there reasons to choose one over the other?
beagle3 7 hours ago [-]
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.
chrsw 3 hours ago [-]
Great explanation. Thanks.
anthk 18 hours ago [-]
The mainline Dillo it's getting UTF8 improved support thanks to that release.
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.
https://en.wikipedia.org/wiki/Nuke_(software)
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.
[1] a quick example is how IRIX vector icons are actually serialised IRIX GL display lists
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)
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...
At 100% scaling, they look they way they're supposed to.[1] But at other scales, particularly non-integer ones, their drawing code will need updating to use the new fl_override_scale()/fl_restore_scale() API.[2] (Now that 1.4.0 is officially out, I expect to get back to maintaining those programs.)
[1]: https://i.imgur.com/A7CvKFe.png [2]: https://groups.google.com/g/fltkgeneral/c/gcqn9EeA7_A/
I am very curious what you mean by this, because they look fine to me.
You know, back when controls were demarcated as controls...
https://xdiskusage.sourceforge.net/
As great as it may be, this isn't something I'd pick as it'd be unusable in this cases.
You should see Windows (10, 11) or Android. Gray on gray, no scrollbars, messages using half of screen, buttons you didn't asked for ( why do i need a microfone icon when the app has no microfone permission ? )
[1] https://github.com/deech/fltkhs
[2] https://github.com/gabdube/native-windows-gui
[3] https://github.com/wiltondb/wiltondb/wiki/WiltonDB-Data-Tran...
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.
0. https://dillo-browser.github.io/
1. https://github.com/dillo-browser/dillo/commits/master/
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.
See: <https://packages.gentoo.org/packages/x11-libs/fltk> and <https://github.com/fltk/fltk/blob/6df2219aa0e56d9632824c94a3...>
snapshot from the wayback machine:
https://web.archive.org/web/20241118160735/https://www.fltk....