FLTK 1.4 Released

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/