How do schemes work?

[supsm17]

Recently there was a thread for a suggestion of a new theme with 1.4. I do not wish to take over that thread, but I wonder how schemes are created in fltk. I found references to Fl_Scheme in the docs, but it does not show how a scheme is created.

Is there any additional information on this? I am interested in creating a scheme of my own (and possibly merge upstream).

[Matthias Melcher]

Themes and schemes are two different things in FLTK world. FLTK 1 supports schemes. Schemes work by changing the box and frame graphics, colors, and optionally by changing the arrow rendering. There is no scheme handbook or documentation. The easiest is to do a search for "scheme", "is_scheme" and similar, and then collect the information found and build a new scheme based on that.

[Albrecht Schlosser]

As Matthias wrote, we don't have documentation on how to create a
scheme, but I believe I described well enough for a start how you could
find your way in the mentioned thread, see this post:
https://groups.google.com/g/fltkgeneral/c/ghiZdIEBFzs/m/JMWiRs5hBQAJ

It doesn't make much sense to document the current way to do it right
now (in 1.4) because ...

My vision is to provide a much better way to create FLTK schemes in FLTK
1.5 (work on this future release is planned to start after the release
of 1.4.0 plus a short period of stabilization, just in case we need some
fixes, i.e. 1.4.x releases.

This new way to create FLTK schemes will work by deriving a subclass
from another FLTK scheme with some well-documented methods that must be
provided (e.g. MyScheme::load() etc.). Ideally a new FLTK scheme would
need one header file and one implementation file that could be compiled
with user projects - or contributed to the FLTK core.

Maybe such a future scheme could also be loaded as a plugin, but that's
very likely wishful thinking, I have no idea if this could work (yet).  ;-)

[Matthias Melcher]

So you are planning to basically backport fltk 2 themes?

[Albrecht Schlosser]

On 4/7/24 20:21 'Matthias Melcher' via fltk.general wrote:
> So you are planning to basically backport fltk 2 themes?

Nope, these are my own thoughts. Changes like the "new" arrow drawing
functions were steps on the path to achieve this, i.e. to isolate scheme
related drawing stuff from widget drawing code - and BTW to unify arrow,
check mark, and radio button drawing across widgets, removing duplicated
code, etc..

But thanks for the hint to look at FLTK 2 as well. I'm not familiar with
FLTK 2 details, but if there's anything we can (re)use, then this should
be done.

I'm not sure though if we're talking about the same things. ISTR that
there was something like setting attributes (like colors) on widgets
that would be inherited by children and so on. That's not what I have in
mind for the "new scheme" stuff. It's more a pragmatic way to simplify
and stabilize scheme generation with the same functionality we have in
1.3 today.

I'm also thinking about better support for "theming", dark mode, etc.,
i.e. setting up new color themes (including the FLTK gray ramp) but
that's really another issue. I believe Greg posted something some time
ago how he is setting different themes (ISTR a 'tan' theme among others)
in his apps. We also have Mike's branch "darkmode" which is a good start
but far from completion.

Nice things to do in 1.5 or later...

[Greg Ercolano]

On 4/7/24 11:44, 'Albrecht Schlosser' via fltk.general wrote:

[..]I believe Greg posted something some time ago how he is setting different themes (ISTR a 'tan' theme among others)
in his apps.

    Yes, that was mainly color map manipulation, a single function that could load hand-crafted ASCII text config files with labels for different colormaps defined as color index to RGB mappings. The labels assign names to each colormap, so that a single file can contain several colormaps, and be loaded based on the label from the UI's menu bar (Edit -> Preferences -> Interface Colors -> (list of labels from file)), so the user can choose different colormaps by clicking the label names in the submenu, e.g.

In that case "Tan" is the currently loaded color theme.

Here's a sample of the config file loaded when the app starts up, trimmed for size:

---

# Dark but not black theme.
#    Good for use in dark studios where comp and render artists
#    keep the lights low for proper monitor colors/low gammas.
#
theme "Dark Grey"
{
    cmap 0 200 200 200  # black: color of most label text
    cmap 1 150 30 30    # red: red tty errors
    cmap 2 0 180 0      # grn: jobs 'Continue' button border color
    cmap 3 180 180 0    # yel
    [..]
    cmap 254 60 66 66           # bgcolor of 'current jobid' lines in tty browser
    cmap 255 50 50 50           # bgcolor of tty
}

# WinXP "Tan" color theme, similar to SGI's motif theme.
#    This I think is the default on WinXP, but implemented here so it can
#    carry over to all platforms.
#
theme "Tan"
{
    cmap 0 0 0 0                # black: color of most label text
    cmap 1 255 0 0              # red: red tty errors
    cmap 2 0 255 0              # grn: jobs 'Continue' button border color
    [..]
    cmap 254 220 240 240        # bgcolor of 'current jobid' lines in tty browser
}

# FLTK's old battleship gray theme.
#    Makes interfaces look "old school" 1990s, and not in a good way.
#
theme "Plain Gray"
{
    cmap 0 0 0 0                # black: color of most label text
    cmap 1 255 0 0              # red: red tty errors
    [..]
    cmap 254 220 240 240        # bgcolor of 'current jobid' lines in tty browser
}

# Black color theme
#     This theme inverts the brightness of the grayscale ramp
#     and brings the white leves down from 255 to approx 180.
#     Colors are also muted so as not to appear overly bright.
#
theme "Black"
{
    # FLTK standard colors.
    #     These have all been muted for the Black color theme,
    #     and black/white brightnesses are inverted.
    #
    cmap 0 140 140 140          # black: color of most label text
    cmap 1 120 0   0            # red: red tty errors
    cmap 2 0  120  0            # grn: jobs 'Continue' button border color
    [..]
 

[Matthias Melcher]

Themes are similar in that they allow runtime loading through a dll. Some docs are here:

https://www.fltk.org/doc-2.0/html/group__themes.html

Themes indeed use Styles to apply attributes to a widget, but that's a second layer. It's very helpful when used correctly, and not very harmful if used incorrectly. A Style holds all the main attributes of a widget, label color, font, size, text color, font, etc. . Every widget type has a default style, but you can add more custom styles. Now if an app has 50 buttons, chances are that at least 48 of them use the same font, color, and fontsize, so instead of setting those for every widget, you just set one style and let all buttons reference one style (except those 2 out of the 50 that I mentioned above,, because they may need a different color or a bold font). Just for the FLUID main menu texts, this is about 90 times where I store a single pointer instead of 4 label attributes each. Plus I can change a single menu item style, and all my manus will change their font.

Some of the Theme stuff you can see in https://github.com/fltk/fltk-legacy/blob/branch-2.0/themes/motif.cxx , for example.

There were some great ideas in that code. 

[supsm17]

>  Themes and schemes are two different things in FLTK world

Apologies, I meant "scheme" rather than "theme" in the original message (changing the style of the box and not just the color).

So from what I can tell, I have to create an implementation file for the theme, then add some glue code in the fl_draw_*.cxx files in the form of

if (Fl::is_scheme("scheme")) ...

Thanks for the help, Mattias, Albrecht, and Greg.