Most active commenters
  • badsectoracula(3)

←back to thread

FLTK 1.4 Released

(www.fltk.org)
113 points mappu | 12 comments | | HN request time: 1.037s | source | bottom
1. mappu ◴[] No.42188498[source]
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...
replies(4): >>42188850 #>>42189064 #>>42189519 #>>42189572 #
2. ilrwbwrkhv ◴[] No.42188850[source]
Those themes look worse than the default ones. We really need aesthetic design sense in the open source community.
replies(1): >>42188898 #
3. bityard ◴[] No.42188898[source]
I'll take a UI that works over one that's pretty any day. (They are almost never both)
4. edflsafoiewq ◴[] No.42189064[source]
Why is the dot in the radio button not centered?
replies(1): >>42189279 #
5. niutech ◴[] No.42189279[source]
This might be rounding error.
6. DidYaWipe ◴[] No.42189519[source]
The default look seems pretty efficient and informative, fairly Windows 95ish.

You know, back when controls were demarcated as controls...

7. badsectoracula ◴[] No.42189572[source]
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...

replies(2): >>42192889 #>>42194107 #
8. lproven ◴[] No.42192889[source]
> All of those look broken

I am very curious what you mean by this, because they look fine to me.

replies(1): >>42195823 #
9. Rangi42 ◴[] No.42194107[source]
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/

replies(1): >>42195856 #
10. badsectoracula ◴[] No.42195823{3}[source]
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

replies(1): >>42213118 #
11. badsectoracula ◴[] No.42195856{3}[source]
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 :-).
12. lproven ◴[] No.42213118{4}[source]
Honestly, no, not really. Both "before" and "after" look fine to me.