←back to thread

FLTK 1.4 Released

(www.fltk.org)
113 points mappu | 1 comments | | HN request time: 0.001s | source
Show context
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 #
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 #
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 #
badsectoracula ◴[] No.42195823[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 #
1. lproven ◴[] No.42213118{3}[source]
Honestly, no, not really. Both "before" and "after" look fine to me.