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)
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.)
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.
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.
You know, back when controls were demarcated as controls...
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.
[1] https://github.com/deech/fltkhs
[2] https://github.com/gabdube/native-windows-gui
[3] https://github.com/wiltondb/wiltondb/wiki/WiltonDB-Data-Tran...
snapshot from the wayback machine:
https://web.archive.org/web/20241118160735/https://www.fltk....
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.
See: <https://packages.gentoo.org/packages/x11-libs/fltk> and <https://github.com/fltk/fltk/blob/6df2219aa0e56d9632824c94a3...>
As great as it may be, this isn't something I'd pick as it'd be unusable in this cases.
Maybe you're thinking of screen-reader support for the blind though.
(I'm not blind, at least yet, but it is a pretty sad state of affairs.)
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 ? )
