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)
A few (historical) contributing factors: FLTK doesn't follow "system" theming or look or integrate with anything. It's not the default of common "desktop evironments". It may also be less portable and lack bindings for the language the dev wants to use.
Both Gtk and Qt, but especially Gtk have those features. Qt also has a lot of corporate backing and jobs advertising. Gtk is the official GNU toolkit(?).
(I would also disagree on developer friendly or simple. But that's opinion of course.)
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.)
Yeah the #1 screenshot looks perfectly fine (except the arrows looking a bit crooked) and how i'd expect them to look. These are some nice screenshots :-).
I already explained it in the post - they look like they are wrongly scaled.
The author of these themes replied a couple of hours ago and he mentioned that indeed it is due to scaling. Compare the image he posted[0] in how the themes were supposed to look with how the images look in the screenshot i replied to and you'll see the issue.
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.
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.
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.
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.
Any hints for a new developer where to start learning FLTK? I like older app aesthetics and interested to build a simple GUI app for personal use. And with Wayland support it looks like to be a more future proof library than say Tcl/Tk
I wonder how FLTK performs against imgui-based apps that have been popping up. I imagine anything being drawn directly on GPU is much faster that xlib shenanigans, specially with fonts.
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.
Untrue. One of the changes mentioned is 1.4 supports scaling the interface with ctrl/+/-/0 (like in your browser). This is a huge accessibility win, the more so because it is now enabled by default for every FLTK program, actually putting it ahead of other toolkits.
Maybe you're thinking of screen-reader support for the blind though.
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 ? )
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)
FLTK remains "Fast and Light", which is how the enlightened minority who wants proper GUIs want it.
A few (historical) contributing factors: FLTK doesn't follow "system" theming or look or integrate with anything. It's not the default of common "desktop evironments". It may also be less portable and lack bindings for the language the dev wants to use.
Both Gtk and Qt, but especially Gtk have those features. Qt also has a lot of corporate backing and jobs advertising. Gtk is the official GNU toolkit(?).
(I would also disagree on developer friendly or simple. But that's opinion of course.)
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.
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...
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.)
[1]: https://i.imgur.com/A7CvKFe.png [2]: https://groups.google.com/g/fltkgeneral/c/gcqn9EeA7_A/
Yeah the #1 screenshot looks perfectly fine (except the arrows looking a bit crooked) and how i'd expect them to look. These are some nice screenshots :-).
> All of those look broken
I am very curious what you mean by this, because they look fine to me.
I already explained it in the post - they look like they are wrongly scaled.
The author of these themes replied a couple of hours ago and he mentioned that indeed it is due to scaling. Compare the image he posted[0] in how the themes were supposed to look with how the images look in the screenshot i replied to and you'll see the issue.
[0] https://i.imgur.com/A7CvKFe.png
Honestly, no, not really. Both "before" and "after" look fine to me.
The default look seems pretty efficient and informative, fairly Windows 95ish.
You know, back when controls were demarcated as controls...
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)
Why is the dot in the radio button not centered?
This might be rounding error.
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.
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/
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...
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.
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/
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....
Any hints for a new developer where to start learning FLTK? I like older app aesthetics and interested to build a simple GUI app for personal use. And with Wayland support it looks like to be a more future proof library than say Tcl/Tk
Found this https://fltk.gitlab.io/fltk/basics.html , looks like a good place to start.
I wonder how FLTK performs against imgui-based apps that have been popping up. I imagine anything being drawn directly on GPU is much faster that xlib shenanigans, specially with fonts.
Wayland finally!
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.
Great explanation. Thanks.
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...>
Zero accessibility =/
As great as it may be, this isn't something I'd pick as it'd be unusable in this cases.
Untrue. One of the changes mentioned is 1.4 supports scaling the interface with ctrl/+/-/0 (like in your browser). This is a huge accessibility win, the more so because it is now enabled by default for every FLTK program, actually putting it ahead of other toolkits.
Maybe you're thinking of screen-reader support for the blind though.
Judging by a sibling comment to yours... it seems a lot of people don't think of supporting blind users.
(I'm not blind, at least yet, but it is a pretty sad state of affairs.)
> 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 ? )