DO NOT REPLY TO THIS MESSAGE.  INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.

[STR New]

Link: https://www.fltk.org/str.php?L2145
Version: 1.4-feature


In my vision we'll have a Fl_Scheme* class hierarchy that will be used in
basic drawing functions like fl_draw_arrow() etc.. I implemented the basics
already in many widgets and for many different objects like
fl_draw_check(), fl_draw_radio() etc. In the future Fl_Widget::draw_focus()
could then call the scheme's method, or something like that. But that's not
yet available.

Extending the fl_box_table array (members) must be considered carefully
because it would potentially break (or at least complicate) existing scheme
additions in the user base. I know of at least one such addition that adds
a user defined scheme in a patch. However, adding a member to the end of a
struct might be uncritical, and at some time we'll have to do it.

If we extended the table, I'd also like a flag that defines whether a
certain boxtype has a background or is a frame type (w/o solid background)
or even FL_NO_BOX (which is definitely 0). This would help us fixing issues
when we (try to) find a parent widget with a background to mark it "dirty"
when e.g. outside labels are drawn multiple times and become "fat" because
of anti-aliasing effects. I believe there's another STR about this effect,
and somewhere in the drawing code we depend on hardcoded boxtypes to
determine the "background or not" property. This additional flag could
either be added as a bit to the existing flag(s) byte or we could add
another member if we change the struct anyway.

Sorry for degressing again, but I felt this is somehow related.


Link: https://www.fltk.org/str.php?L2145
Version: 1.4-feature