On 4/27/21 8:53 AM Greg Ercolano wrote:
On 4/26/21 11:29 PM, Webb Hinton wrote:
What do people think about offering a "Flat" scheme for FLTK?
I think this would make for a lot of out of the box appeal, and when
people are shopping around for GUI libraries, having a couple style
options is certainly a big plus.
I like the idea -- just in the last week or so I had to make an
FLTK project with a flat
UI to spec. It was easy to do though by just changing the buttons
and playing around with the colors.
But it would be nice if it could all be switched with Fl::scheme().
There are some limitations of what we can do with FLTK schemes. The
majority of possible changes is related to drawing boxes. Specifically
"playing around with the colors" is /not/ a scheme option, this would
need to be done at application level - if e.g. button colors in the
"flat" scheme need to be different than in other schemes.
Of course you can also change the internal color table when switching
schemes in your application.
A flat scheme would be easier to implement than the other schemes
we have already, as there's probably not much to it.
The minimal approach is to overwrite all or some box drawing functions
which could be all you need to do here. Call the FL_FLAT_BOX drawing
function for all box types (but not FRAME types) or something similar to
Drawing decent box shapes (rounded corners) is just one drawing function
that needs to be implemented if this is desired.
Also, now that FLTK has SVG, that could be leveraged for
to do the subtle curves on the buttons and boxes, if one wanted to
Yep, that would also be an option for box drawing.
FLTK 1.x doesn't really provide an "easy" way for end users to
re-theme all the FLTK widgets; IIRC you pretty much have to
hack FLTK's code to add a new scheme. So providing, for
example, an SVG based scheme wouldn't be something
one could do as an external project AFAIK.. unless it were provided
as a patch.
Unfortunately this is the case. Basically only new box drawing code is
*required* (see the "gleam" scheme) but to activate the new boxtypes
there's some glue code and changes in the box type enumeration necessary
which can currently only be done in a library patch.
It's been discussed to provide a way to allow scheming more
easily, but I don't think anyone's come up with a demo, let
alone an API design that works for 1.x.
I've been working on this and my basic API design is a base class
Fl_Scheme with derived classes Fl_Scheme_Gtk, Fl_Scheme_Gleam and so on.
My vision is to be able to add a new scheme in one source and one header
file in user code or maybe even as a plugin. Since each scheme inherits
a parent scheme class you would "only" need to override some virtual box
and maybe other drawing methods with minimal code.
Registering a new scheme at runtime would automatically add it to
(Fl_Choice) scheme selections so you could also test it in fluid, demo,
and unittests and you could provide your own Fl_Choice scheme selection
widget or menu with all /currently/ available (i.e. loaded) schemes.
I got the basics working but there's still much to do before I can
provide a fully working prototype.
My working model is the long-standing addition of the "oxy" scheme which
is similar but IMHO superior to the "gleam" scheme but its
implementation needs too many patches in the FLTK core. I hope I can
simplify this to the "one source and one header file" approach.
I think FLTK 2.x might have provided this, not sure..
I never got familiar with 2.x
Neither did I (get familiar ..). But ISTR that there has been a "style"
definition (colors and such) that could be "inherited" by different
widgets so you could switch the appearance of many or all widgets at
once by modifying a base style in one place rather than changing all
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to email@example.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/94658e9e-b50d-4e88-fa2d-c954522badd2%40online.de.
[ Direct Link to Message ]