Re: [fltk.general] "Flat" App Scheme

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 All Forums  |  Back to fltk.general  ]
Previous Message ]New Message | Reply ]Next Message ]

Re: "Flat" App Scheme Albrecht Schlosser Apr 27, 2021 top right image
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 to FL_FLAT_BOX
     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 that.

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 antialiased lines     to do the subtle curves on the buttons and boxes, if one wanted to get "fancy".

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 widgets.

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
To view this discussion on the web visit
Direct Link to Message ]
bottom left image   bottom right image
Previous Message ]New Message | Reply ]Next Message ]

Comments are owned by the poster. All other content is copyright 1998-2022 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to ''.