FLTK 1.4 Menu Bar Style

[Daniel Harding]

In FLTK 1.4, "highlighted" menu bar items (and submenu items) are indicated with either an up box or a light background:

 

I much prefer the stronger contrast of using the FL_SELECTION_COLOR in FLTK 1.3:

I took a look at Fl_Menu_Item::draw() in Fl_Menu.cxx but it didn't seem clear how to customize a Fl_Menu_Bar to get the same effect.

Using test/editor.cxx as an example, I can add app_menu_bar->box(FL_FLAT_BOX); to replace the up box with a flat box, but I can't figure out how to always use FL_SELECTION_COLOR as the selected background color. (app_menu_bar->selection_color(FL_SELECTION_COLOR); as no affect and app_menu_bar->color(FL_SELECTION_COLOR); makes every non-selected menu item use the selection color.)

I also think the new style of the submenu arrows is a bit exaggerated:

And I think the more modest look of FLTK 1.3 arrows was more appropriate:

Is it possible to customize this?

Thanks for any advice.

[Manolo]

Adding

    app_menu_bar->selection_color(FL_DARK_BLUE);

to whatever menu of your app will restore the blue background.

@Albrecht: the call to fl_contrast() at line 288 of file sc/Fl_Menu.cxx gives a different result under Windows

than under X11 and macOS. That's the cause of the changed menu behavior. Is it wanted?

[Manolo]

see issue 969: https://github.com/fltk/fltk/issues/969

[Albrecht Schlosser]

On 5/6/24 04:09 Daniel Harding wrote:

In FLTK 1.4, "highlighted" menu bar items (and submenu items) are indicated
with either an up box or a light background:

[image: 1.png]

I much prefer the stronger contrast of using the FL_SELECTION_COLOR in FLTK
1.3:

[image: 2.png]

I took a look at Fl_Menu_Item::draw() in Fl_Menu.cxx but it didn't seem
clear how to customize a Fl_Menu_Bar to get the same effect.

Using test/editor.cxx as an example, I can add
app_menu_bar->box(FL_FLAT_BOX); to replace the up box with a flat box, but
I can't figure out how to always use FL_SELECTION_COLOR as the selected
background color. (app_menu_bar->selection_color(FL_SELECTION_COLOR); as no
affect and app_menu_bar->color(FL_SELECTION_COLOR); makes every
non-selected menu item use the selection color.)

It's always difficult to reply to two different issues in one post. I'll reply to this part later to Manolo's comment.

I also think the new style of the submenu arrows is a bit exaggerated:

[image: 4.png]

And I think the more modest look of FLTK 1.3 arrows was more appropriate:

[image: 3.png]

I agree that the new arrows look a bit too large in your screenshots. For digging deeper into details please tell us which 1.3.x version you are using, just in case this changed during 1.3.x development.

There are also differences per FLTK scheme, so please tell us also which scheme you used for your tests.

Is it possible to customize this?

This is not customizable by FLTK users (developers of applications *using* FLTK). However, I think it would be appropriate to limit the size of the arrows to a certain maximum to be more compatible to 1.3.x.

I'm working on a modification, but please answer my questions above nevertheless. This would be very helpful.

One important notice: the new "arrow drawing" functions in FLTK 1.4 standardize the arrow drawing for all widgets and menus and whatever. The old code in 1.3 used "manual" arrow drawing functions "everywhere" which resulted in a different look of arrows (mostly a kind of triangles, but the GTK+ scheme is a little different) in different widgets and menus. The new "oxy" scheme in 1.4 added even more to the complexity.

The new 1.4 arrow drawing functions unify this. Such "arrows" are now looking the same in all widgets and menus but can be different *per scheme* (as said before, "gtk+" is different than the "base" scheme but also different than the "oxy" scheme).

That said, it must be obvious that some of the "hand made" arrow drawing functions produced different results in 1.3 than the new drawing functions in 1.4. This is neither a bug nor a regression - it's a feature. ... Unless something went awry in the transition from 1.3 arrow drawing to 1.4. arrow drawing in general.

The submenu arrows appear to be such a case which is why I'm investigting this. Thanks for your report.

Thanks for any advice.

I'm not sure if there's anything you can do yourself. Reporting the issue was a first good step, I appreciate this very much.

(Don't forget to answer my questions above)

[Albrecht Schlosser]

On 5/6/24 12:15 Manolo wrote:

Adding
    app_menu_bar->selection_color(FL_DARK_BLUE);
to whatever menu of your app will restore the blue background.

Well, this might be a workaround, but setting a specific selection color (other than the default selection color of the system or theme) would IMHO be a bad choice in general. We should find a better solution.

Imagine a user selecting a dark theme and the code sets FL_DARK_BLUE as the selection color, or the system uses a "green" or "tan" theme (as Greg posted recently). In such a case setting a dark blue selection color on menus (only) would certainly be a bad choice, at the very least very inconsistent.

@Albrecht: the call to fl_contrast() at line 288 of file sc/Fl_Menu.cxx
gives a different result under Windows than under X11 and macOS.
That's the cause of the changed menu behavior. Is it wanted?

No, that isn't intended but it's much more complicated than just that "simple" question. This code has not been changed for a long time, and if `fl_contrast()` yields a different result than in 1.3 than this is most likely intended. In this case FLTK 1.3 allowed a color combination with too little contrast whereas 1.4 notices that the contrast is too low.

Honestly, I don't really understand the code around line 288 in that file. The mentioned line:
```

if (fl_contrast(r, color) != r) { // back compatibility boxtypes

```

seems to be the wrong way around, and I don't understand what that comment means.
<rant>What is it good for, if you don't understand it?</rant>
Sorry, no offense intended, whoever is responsible for this comment - it's late here!!!.

I would say the code should query whether the foreground color (i.e. 'color') is the same if fl_contrast() is applied, like this:
```

  if (fl_contrast(color, r) != color) { // ?? text color 'color' has not enough contrast... ??

```

... and then do whatever is required...

(disclaimer: unless I misunderstood what the code is intended to do).

The following lines seem to replace the background color which is IMHO NOT what we want (see my comment to issue #969:
https://github.com/fltk/fltk/issues/969#issuecomment-2097056656

```

if (selected == 2) { // menu title

r = color;

b = m ? m->box() : FL_UP_BOX;

} else {

r = (Fl_Color)(FL_COLOR_CUBE-1); // white // This makes the background white **BAD**

l.color = fl_contrast((Fl_Color)labelcolor_, r); // This selects a contrasting text color **OK?**

}

```

So, yes, I agree that this is the culprit, but since I don't know what it is intended to do (and why) I have no idea how to fix it.

Maybe Matt who is more familiar with menu code can shed some light on this issue?

That said, whoever takes this: **please** change at least some of these single-letter variable names (r, b, and maybe m and l) to something a reader can understand! Sorry for the rant, again!

Good night.

[Daniel Harding]

On Monday, May 6, 2024 at 5:28:23 PM UTC-5 Albrecht-S wrote:

It's always difficult to reply to two different issues in one post. I'll reply to this part later to Manolo's comment.

Sorry about that.

I agree that the new arrows look a bit too large in your screenshots. For digging deeper into details please tell us which 1.3.x version you are using, just in case this changed during 1.3.x development.

The 1.3 screenshots from above are from git tag release-1.3.8.

There are also differences per FLTK scheme, so please tell us also which scheme you used for your tests.

 

The screenshots all use the base scheme. I also have the same feeling about the gtk+ scheme with slightly large menu arrows. I haven't spent any time observing any other schemes.

Thanks for the additional info and background.

===

Matthias' comment on github issue #969 led me on a hunt where I found fl_contrast_mode(FL_CONTRAST_LEGACY); which is sufficient at the very least for my needs.

If you all choose to improve the "new" contrast function even further, then great. But at least I have the "legacy" contrast function in any case. Thanks for making that available.

In case these practical examples are helpful, here are the 12 themes in my application with FLTK 1.3.8:

And here are the themes in FLTK 1.4 with the new/default contrast function:

The number of themes where the selection color was replaced with white changed from 2/12 in FLTK 1.3.8 to 8/12 in FLTK 1.4, and in many of the cases I think the contrast function was "too aggressive" but of course that's only my subjective opinion.

How to improve it (if at all) I will leave up to all of you.

What's also interesting (at least somewhat) is that the contrast function is also forcing many of the radio buttons and check marks to be black instead of the selection color, even when I think the selection color looks good.

[Daniel Harding]

FTR, if it was changed such that 0 out of 12 themes had their selected menu background color "flipped" to white (as opposed to 2 out of 12 being flipped in FLTK 1.3.8), I think that would be even better. (I'm not striving for backwards compatibility per se.) I think it would make sense for it the be the user's responsibility to ensure the current selection color contrasts adequately with the current background color and then in turn FLTK always honored the selection color, as is being discussed in the github issue. In other words, perhaps the new contrast function isn't too aggressive at all -- just not needed in this case.

[Albrecht Schlosser]

On 5/7/24 02:20 Daniel Harding wrote:

On Monday, May 6, 2024 at 5:28:23 PM UTC-5 Albrecht-S wrote:

> I agree that the new arrows look a bit too large in your screenshots. For
> digging deeper into details please tell us which 1.3.x version you are
> using, just in case this changed during 1.3.x development.

The 1.3 screenshots from above are from git tag release-1.3.8.

Thanks for the screenshots, they are very helpful, particularly those with all your themes.

Seeting up your different themes for testing would be a big help. Is your program open source, can you share a link so we can test, or can you share the theme setup and we can create our own "themes" for testing?

The screenshots all use the base scheme. I also have the same feeling about
the gtk+ scheme with slightly large menu arrows. I haven't spent any time
observing any other schemes.

I limited the menu arrow size in commit 866a4a4fcb6c564b067cce38a90696645fab7c0e. Please test and report if this is "better". However, note that there may be different opinions ("arrows are now too small") and we may set the limit higher in the future.

Thanks for the additional info and background.

Welcome.

Matthias' comment on github issue #969 led me on a hunt where I found
fl_contrast_mode(FL_CONTRAST_LEGACY); which is sufficient at the very least
for my needs.

Yup, that was the intention, keeping the old function for border cases where programs need the old (legacy) behavior. But you should keep in mind that this algorithm doesn't calculate correct contrast values WRT visual perception.

If you all choose to improve the "new" contrast function even further, then
great. But at least I have the "legacy" contrast function in any case.
Thanks for making that available.

There are currently no plans to improve the (new) fl_contrast() method in 1.4.x but there may be another method in a later FLTK version. You can even write your own and use that (see the docs).

There's another, much simpler, option to fine-tune the new fl_contrast() method to make it "less aggressive": fl_contrast_level().
https://www.fltk.org/doc-1.4/group__fl__attributes.html#ga5cb53fa508f3e45a0ccab46151461a2c

See the docs for how to set this, and maybe setting the level lower than the default (55 for the new mode) can help to achieve what you want. However, I do not recommend changing the contrast level, at least not lower than 50.

In case these practical examples are helpful, here are the 12 themes in my
application with FLTK 1.3.8: [image]
And here are the themes in FLTK 1.4 with the new/default contrast function: [image]

Great, thank you very much. See my question above for source code for my testing.

The number of themes where the selection color was replaced with white
changed from 2/12 in FLTK 1.3.8 to 8/12 in FLTK 1.4, and in many of the
cases I think the contrast function was "too aggressive" but of course
that's only my subjective opinion.

How to improve it (if at all) I will leave up to all of you.

As I wrote on GitHub Issue #969 I believe that the current code is not as it should be. Manolo proposed a change in that Issue which looks IMHO much better, although he also writes that it's not the final solution. But we'll investigate this further.

What's also interesting (at least somewhat) is that the contrast function
is also forcing many of the radio buttons and check marks to be black
instead of the selection color, even when I think the selection color looks
good.

Thanks for this comment too, I noticed this fact as well. I'll check this...

[Albrecht Schlosser]

On 5/7/24 02:39 Daniel Harding wrote:
> FTR, if it was changed such that 0 out of 12 themes had their selected menu
> background color "flipped" to white (as opposed to 2 out of 12 being
> flipped in FLTK 1.3.8), I think that would be even better. (I'm not
> striving for backwards compatibility per se.)

As already said, this will be investigated further.

> I think it would make sense
> for it the be the user's responsibility to ensure the current selection
> color contrasts adequately with the current background color and then in
> turn FLTK always honored the selection color, as is being discussed in the
> github issue. In other words, perhaps the new contrast function isn't too
> aggressive at all -- just not needed in this case.

Unfortunately it's not possible to select adequately contrasting colors
by the program developer. Users of the program can run them on a variety
of systems and use a variety of system "themes" (KDE, Gnome, other DE's)
and FLTK always tries to honor the system "theme", i.e. the background
and selection colors. This is why you see the different colors in issue
#969 posted by Manolo. In fact I had to *introduce* another call to
fl_contrast() somewhere recently (may be some months ago) where a user
reported that the system's background color and selection color were the
same which obviously didn't work well.

Therefore fl_contrast() *must* be used in several places, but (I'm
repeating myself) the current usage that flips the color of the selected
menu item may be wrong. Some code in FLTK is pretty old and may have
undiscovered issues like this which depend highly on the system environment.

But again, we'll check this.

[Daniel Harding]

On Tuesday, May 7, 2024 at 9:44:51 AM UTC-5 Albrecht-S wrote:

Seeting up your different themes for testing would be a big help. Is your program open source, can you share a link so we can test, or can you share the theme setup and we can create our own "themes" for testing?

My repo is here: https://github.com/dannye/crystal-tracker

With an fltk1.4 branch here: https://github.com/dannye/crystal-tracker/tree/fltk1.4

Although with the libopenmpt and PortAudio dependencies, it's a little tedious to build. At least, tedious on Windows. Building on Linux isn't that bad.

But the themes come straight from this other open source (LGPL) repo here:

https://github.com/Rangi42/polished-map

which is easier to build (fewer dependencies). Although this repo is so far only compatible with FLTK 1.3.

All the themes come from src/themes.cpp (in either repo).

I limited the menu arrow size in commit 866a4a4fcb6c564b067cce38a90696645fab7c0e. Please test and report if this is "better". However, note that there may be different opinions ("arrows are now too small") and we may set the limit higher in the future.

I can't find commit 866a4a4fcb6c564b067cce38a90696645fab7c0e in the fltk repo or your fork of it.

There's another, much simpler, option to fine-tune the new fl_contrast() method to make it "less aggressive": fl_contrast_level().

https://www.fltk.org/doc-1.4/group__fl__attributes.html#ga5cb53fa508f3e45a0ccab46151461a2c

See the docs for how to set this, and maybe setting the level lower than the default (55 for the new mode) can help to achieve what you want. However, I do not recommend changing the contrast level, at least not lower than 50.

I'm optimistic that once the planned improvement is made to menu item drawing, neither fl_contrast_mode() nor fl_contrast_level() will be necessary for me.

Thanks.

[Daniel Harding]

On Tuesday, May 7, 2024 at 9:53:34 AM UTC-5 Albrecht-S wrote:

Unfortunately it's not possible to select adequately contrasting colors
by the program developer. Users of the program can run them on a variety
of systems and use a variety of system "themes" (KDE, Gnome, other DE's)
and FLTK always tries to honor the system "theme", i.e. the background
and selection colors.

Interesting. I see your point. I suppose I don't consider this very much because from my selfish point of view, my application only runs in 1 of 12 "fully built" themes that don't rely at all on any system defaults (AFAIK).

It makes me wonder if FLTK is aware of whether any "system defaults" are still "in play" or not. If FLTK is capable of being aware of this, then perhaps it could be more "hands off" and not meddle with theming as much when there are no more "unpredictable" system defaults. (ie, only compensate for poor contrast whenever a system default is the culprit.)

Of course, if FLTK is not already capable of making this distinction, then this is only a hypothetical suggestion; not a very serious one.

But I do think there is value in letting the user developer have the option to take the responsibility of ensuring the theme has adequate contrast, and in return FLTK will not tamper with it so much (except, for example, in the "obvious" cases like simply making sure foreground text contrasts with the background which is virtually always desirable).

[Albrecht Schlosser]

Daniel, please make sure that citations are marked as such. It's hard to find out what a citation and what your new text is (particularly for someone not so much involved in the current thread). In this case I removed all citations and replied only to your text.

On 5/7/24 17:37 Daniel Harding wrote:

My repo is here: https://github.com/dannye/crystal-tracker
With an fltk1.4 branch here:
https://github.com/dannye/crystal-tracker/tree/fltk1.4
Although with the libopenmpt and PortAudio dependencies, it's a little
tedious to build. At least, tedious on Windows. Building on Linux isn't
that bad.

I would only build it on Linux, maybe I can give it a try.

But the themes come straight from this other open source (LGPL) repo here:
https://github.com/Rangi42/polished-map

which is easier to build (fewer dependencies). Although this repo is so far
only compatible with FLTK 1.3.

That wouldn't matter. I could certainly make everything I need compatible with 1.4 (if there is any need - it shouldn't in most cases).

All the themes come from src/themes.cpp (in either repo).

Thanks, I'll look into it when time permits. I believe that "theming" will be a new feature in 1.5.0, and basing this on a working example would be great. If its license is compatible with FLTK's license, of course - and LGPL, as you wrote, is "the same" license.

I can't find commit 866a4a4fcb6c564b067cce38a90696645fab7c0e in the fltk
repo or your fork of it.

Sorry, I missed to push my commits while doing the last tests. The new commit is now 60690dba51a50c5ae3aef035b3b824f3646f2e3d but you can pull the latest from master.

I'm optimistic that once the planned improvement is made to menu item
drawing, neither fl_contrast_mode() nor fl_contrast_level() will be
necessary for me.

Yes, that's my thought and hope as well, I just wanted to mention it.

[Albrecht Schlosser]

On 5/7/24 18:00 Daniel Harding wrote:
> On Tuesday, May 7, 2024 at 9:53:34 AM UTC-5 Albrecht-S wrote:
>
> > Unfortunately it's not possible to select adequately contrasting colors
> > by the program developer. Users of the program can run them on a variety
> > of systems and use a variety of system "themes" (KDE, Gnome, other DE's)
> > and FLTK always tries to honor the system "theme", i.e. the background
> > and selection colors.
>
> Interesting. I see your point. I suppose I don't consider this very much
> because from my selfish point of view, my application only runs in 1 of 12
> "fully built" themes that don't rely at all on any system defaults (AFAIK).

One of the main points is whether you call Fl_Window::show(argc, argv)
or use the one w/o arguments. The former reads system color schemes
etc., as well as if you call Fl::get_system_colors() which should be
obvious. If you don't call either, then FLTK is -  AFAICT - always in
its "default state" after startup.

> It makes me wonder if FLTK is aware of whether any "system defaults" are
> still "in play" or not. If FLTK is capable of being aware of this, then
> perhaps it could be more "hands off" and not meddle with theming as much
> when there are no more "unpredictable" system defaults. (ie, only
> compensate for poor contrast whenever a system default is the culprit.)

That's very likely not going to happen, for certain reasons...

> Of course, if FLTK is not already capable of making this distinction, then
> this is only a hypothetical suggestion; not a very serious one.

OK.

> But I do think there is value in letting the user developer have the option
> to take the responsibility of ensuring the theme has adequate contrast, and
> in return FLTK will not tamper with it so much (except, for example, in the
> "obvious" cases like simply making sure foreground text contrasts with the
> background which is virtually always desirable).

Now we're back to the point where I need to say that this (as you
describe) is the intention of using fl_contrast() anywhere. The example
we talked about seems to be a bug and not the intended behavior. I think
we agree and we should be patient to see what we can find out before we
talk about hypothetical issues. ;-)

But anyway, all comments are appreciated, thank you.

[Daniel Harding]

On Tuesday, May 7, 2024 at 1:19:33 PM UTC-5 Albrecht-S wrote:

Daniel, please make sure that citations are marked as such. It's hard to find out what a citation and what your new text is (particularly for someone not so much involved in the current thread). In this case I removed all citations and replied only to your text.

Hm? Can you please elaborate on what you mean by this? I am very careful and consistent about this already.

 Citation quotes in my replies are always 1) purple, 2) indented, and 3) have the vertical line "quote block" style along the left (the default by Google Groups in the web browser).

Example:

Can you share an example of how it looks unclear on your end?

[Albrecht Schlosser]

On 5/7/24 20:31 Daniel Harding wrote:

On Tuesday, May 7, 2024 at 1:19:33 PM UTC-5 Albrecht-S wrote:

Daniel, please make sure that citations are marked as such. It's hard to
find out what a citation and what your new text is (particularly for
someone not so much involved in the current thread). In this case I removed
all citations and replied only to your text.


Hm? Can you please elaborate on what you mean by this? I am very careful
and consistent about this already.

 Citation quotes in my replies are always 1) purple, 2) indented, and 3)
have the vertical line "quote block" style along the left (the default by
Google Groups in the web browser).

Can you share an example of how it looks unclear on your end?

(1) See above, this is what I saw in your reply. My text ("Daniel, please ...") and your "Hm? ..." could not be distinguished by any means.

(2) I just noticed that I had changed Thunderbird's "view" menu to text mode which resulted in this issue.

Now I changed the View mode to one of its HTML options, and I can see citations distinguishable from your reply. So far I apologize, it was (in parts) my fault.

That said, in the mail protocol Google doesn't seem to support all its "gimmicks", and thus I can see neither "purple" nor the indentation, whereas I can see a vertical line at the left border. That's not what you see in the Google Groups web interface (your screenshot) but it's sufficient. Many of the FLTK devs don't like Google's web interface.

The following screenshot is what I see in "Original HTML" view (truncated at the right side to make it smaller:

<screenshot>

<end of screenshot>

Thanks for clarification.

[Daniel Harding]

On Tuesday, May 7, 2024 at 1:19:33 PM UTC-5 Albrecht-S wrote:

  Sorry, I missed to push my commits while doing the last tests. The new commit is now 60690dba51a50c5ae3aef035b3b824f3646f2e3d but you can pull the latest from master.

The slightly reduced arrow size is great now. Thank you for making that tweak. I think it's a real improvement.

This is what a submenu arrow looked like in 1.3:

There is a margin of 5 pixels above the arrow and 4 pixels below the arrow.

And this is what the submenu arrow looks like now in 1.4 after your tweak:

I think the size is good. There is a margin of 5 pixels above and 2 pixels below.

This is how it would look moved just 1 pixel up so that there is a margin of 4 pixels above and 3 pixels below:

I think it looks really nice well-centered in its row, which is also more similar to 1.3.

I'm curious if you agree and if that is a simple enough change to make (without too many far-reaching consequences).

Thanks again.

[Daniel Harding]

And in case a little more context is helpful, the screenshots in my previous message were from my own application and on Linux/X11.

Here is a screenshot on Windows 11 with the default test/menubar program:

The smaller arrow size looks great, and it has the 5/2 margin just like X11 that I think would look better as 4/3.

[Manolo]

The original 1.4 problem of selected menu items not drawn on blue background under Windows

is now fixed in the FLTK git repo.

[Albrecht Schlosser]

On 5/8/24 04:39 Daniel Harding wrote:

On Tuesday, May 7, 2024 at 1:19:33 PM UTC-5 Albrecht-S wrote:

  Sorry, I missed to push my commits while doing the last tests. The new commit is now 60690dba51a50c5ae3aef035b3b824f3646f2e3d but you can pull the latest from master.

The slightly reduced arrow size is great now. Thank you for making that tweak. I think it's a real improvement.

...

And this is what the submenu arrow looks like now in 1.4 after your tweak:

...

I think the size is good. There is a margin of 5 pixels above and 2 pixels below.

This is how it would look moved just 1 pixel up so that there is a margin of 4 pixels above and 3 pixels below:

...

I think it looks really nice well-centered in its row, which is also more similar to 1.3.

I'm curious if you agree and if that is a simple enough change to make (without too many far-reaching consequences).

I agree that better centering makes it look better. The reason it was off by one pixel was accumulated rounding effects.

This is now fixed in FLTK 1.4, current master: commit 79ddf2f2b854aac373123620b8c722f81f4fbdaa

However, note that it's not always possible to find the "optimal" position due to rounding effects (what is the middle of an even number?). I put a lot of effort in drawing the "oxy" arrows (i.e. arrows in the "oxy" scheme) in proper positions. IMHO it looks pretty good now, but depending on widget sizes there could still be 1-off issues somewhere...

Anyway, this issue should be done now.

Is there still anything I missed?

[Daniel Harding]

On Thursday, May 9, 2024 at 1:15:39 PM UTC-5 Albrecht-S wrote:

This is now fixed in FLTK 1.4, current master: commit 79ddf2f2b854aac373123620b8c722f81f4fbdaa

Thank you, looks great.

Is there still anything I missed?

 The only other minor issue is this:

What's also interesting (at least somewhat) is that the contrast function is also forcing many of the radio buttons and check marks to be black instead of the selection color, even when I think the selection color looks good.

Thanks for this comment too, I noticed this fact as well. I'll check this...

Currently, 4 of my 12 themes have their selection color replaced with black for radio buttons and check marks:

1.3.8:

1.4:

But I understand that the light blue is a little light. This may just be a case where the new and improved contrast function simply legitimately has a different result than the old contrast function.

Although I would really like for it to use the selection color in each of these cases.

I have to set the contrast level to 36 to "fix" all 4 themes, which is too low -- it messes with text contrast, which is to be expected. (Although, I was surprised I had to go as low as 36 to get the light blue to display on top of the white background.)

I think my only other option is to use the legacy contrast mode, which will pretty easily fix all 4 cases.

This switch-to-black is the result of this line of code:

https://github.com/fltk/fltk/blob/da58045/src/Fl_Menu.cxx#L304

just in case you think there's any way that it can be improved. But I completely understand if you say it should be left as-is. (Legacy contrast mode will do for my needs.)

Thanks again for everything.

P.S. I'm really curious if the new-but-unused 'context' argument for fl_contrast() could be used here to say "These radio buttons and check marks are not text, so they do not need quite as aggressive contrast checking as text.", but that's just an idea.

[Manolo]

Le jeudi 9 mai 2024 à 23:20:14 UTC+2, Daniel Harding a écrit :

Currently, 4 of my 12 themes have their selection color replaced with black for radio buttons and check marks

To me, this means that we should remove, when preparing FLTK 1.5, the special transformation of the blue hue

used for selection color done in the Windows platform and have it use the same color as that used by other platforms.

[Daniel Harding]

This has *nothing* to do with Windows. Most screenshots in this thread were on Linux, which is also irrelevant because the output is the same on all platforms. [1]

This has only to do with fl_contrast(), Fl_Menu_Item::draw(), and whether a programmer's (platform-independent) selection color should be honored by FLTK.

It is my subjective opinion that this blue selection color (used by 4 of my platform-independent themes) is good and should be "allowed" as the accent color for FL_MENU_TOGGLE and FL_MENU_RADIO menu items.

One way to accomplish this would be to use the new "context" parameter of fl_contrast() where a default context of "0" would apply the "contrast level" as-is, but a context of "1" (toggle/radio accent) could, for example, mean to apply fl_contrast_level()*0.7 or something similar. (Just an example.)

===

[1] This is also why I recommend GitHub issue #969 have the "Platform: Windows" label removed.

[Albrecht Schlosser]

On 5/9/24 23:20 Daniel Harding wrote:

On Thursday, May 9, 2024 at 1:15:39 PM UTC-5 Albrecht-S wrote:

This is now fixed in FLTK 1.4, current master: commit 79ddf2f2b854aac373123620b8c722f81f4fbdaa

Thank you, looks great.

Welcome.

Is there still anything I missed?

 The only other minor issue is this:

What's also interesting (at least somewhat) is that the contrast function is also forcing many of the radio buttons and check marks to be black instead of the selection color, even when I think the selection color looks good.

Thanks for this comment too, I noticed this fact as well. I'll check this...

Currently, 4 of my 12 themes have their selection color replaced with black for radio buttons and check marks:

[... images removed ...]

But I understand that the light blue is a little light. This may just be a case where the new and improved contrast function simply legitimately has a different result than the old contrast function.

Yup, indeed.

Although I would really like for it to use the selection color in each of these cases.

I have to set the contrast level to 36 to "fix" all 4 themes, which is too low -- it messes with text contrast, which is to be expected. (Although, I was surprised I had to go as low as 36 to get the light blue to display on top of the white background.)

I think my only other option is to use the legacy contrast mode, which will pretty easily fix all 4 cases.

There are other options. AFAICT you are deliberately setting the background color (FL_BACKGROUND2_COLOR) and the selection color (FL_SELECTION_COLOR) according to your "themes" but you are free to adjust the themes, aren't you? I looked into the code by the link you gave me (not your code but the other code you copied or derived your code from), and I found the according colors of the four themes that still change the color of the radio buttons to black.

Before I go into details, making all these colors somewhat darker but keeping the hue would fix the issue for the given themes. Note that I didn't test the code of the themes directly, I used two FLTK test programs to find the results (better than trial and error using an application program, IMHO).

So, here's what I suggest if you want to keep the default algorithm (CIELAB) and level (55) and change only the selection color:

- Themes AERO and METRO: change selection color from (0x33, 0x99, 0xff) to (0x26, 0x73, 0xbf).
- Theme Greybird: change (0x50, 0xa0, 0xf4) to (0x39, 0x71, 0xad)
- Theme Rose Gold: change (0x15, 0x81, 0xfa) to (0x12, 0x6e, 0xd6)

I'm aware that this makes all selection colors darker but it keeps the hue and produces the desired results. It's only one possible option.

Reducing the contrast level to something around 50 would allow different, brighter selection colors that are still "accepted". See below for advice how I found the values.

This switch-to-black is the result of this line of code:

https://github.com/fltk/fltk/blob/da58045/src/Fl_Menu.cxx#L304

just in case you think there's any way that it can be improved. But I completely understand if you say it should be left as-is. (Legacy contrast mode will do for my needs.)

Well, this is exactly the point where I had to introduce the call to fl_contrast() in the past. Your suggestion to use FL_SELECTION_COLOR directly was previously implemented but resulted in absolutely NO contrast in a user's system configuration. See GitHub Issue #443 "gtk+ rendering". On the user's system the two colors were the same (according to his tests) ! Using fl_contrast() was the logical conclusion, altough you could have said, the user should "repair" their system settings that led to this status. But OTOH, other systems might suffer from similar effects.

Therefore this can't be changed.

Thanks again for everything.

Your comments are absolutely appreciated. I wouldn't spend that much time if I didn't consider your comments useful. Thanks for your constructive comments.

P.S. I'm really curious if the new-but-unused 'context' argument for fl_contrast() could be used here to say "These radio buttons and check marks are not text, so they do not need quite as aggressive contrast checking as text.", but that's just an idea.

Good point, that's absolutely correct! This currently unused argument has exactly this purpose. But this has not yet been implemented for a reason and I won't touch it in 1.4.0 because this would open another dimension of contrast calculation. We'd have the "level" and e.g. the font size or some other classification of object size which span at least a two-dimensional matrix (if we distinguish object types - font, radio button, checkmark - we'd even have three dimensions. The usage for text contrast would be to use the font size and reduce the required contrast value for larger fonts. OTOH other "objects" (like radio buttons) might require even less contrast.

The background is the theory (and not only a theory, it's real) that contrast perception depends on the "size" of objects (much simplified). If you are interested in the details, read all the comments on GitHub Issue #370: "Not enough contrast on automatic colors" and the theory about APCA (details below). This issue led to the implementation of the new "CIELAB" contrast mode.
https://github.com/fltk/fltk/issues/370

In a nutshell: a supposedly even better algorithm would be APCA ( https://www.myndex.com/APCA/ ) which is (well, was at that time) supposed to be used in a new web standard. Currently you can read on its site: "APCA W3 is in public beta". I didn't follow the entire development during the last year, but at the time when I checked it, it was not possible to use APCA in our software because of licensing reasons, and that was in parts due to its beta status. The result was to implement the freely available CIELAB standard which gives us a much better contrast value than the "legacy" algorithm used in 1.3 but APCA might be a further step later.

In a future FLTK version we might use the context argument and font sizes or whatever, maybe together with the APCA algorithm, but this is not doable in the current 1.4.x releases. Just to let you know...

----

OK, so far the theory, back to practice: my original assumption was that contrast level 50 (which corresponds to "50%") would be "enough". But testing with the new test/contrast.cxx program revealed that it didn't seem to be sufficient in all cases. The default value 55 was chosen deliberately and made the new algorithm a little more "aggressive", i.e. it requires a higher contrast to be "sufficient". That said, if you think that a lower value (50 - 54) is better for your program and sufficient for your users, feel free to reduce the contrast level to 50 (but I would not recommend values below 50).

What can you do to find satisfying background and selection colors?

Maybe trial and error, but here's what I did:

Tool 1 is our test/color_chooser.cxx program. Launch it and enter a color value, e.g. the selection color of the Rose Gold theme: (0x15, 0x81, 0xfa).



Then use the slider to reduce the brightness by keeping the hue. Note that the "green" value has the largest effect on brigthness (or lightness, or luminance).



You can see the differing but similar colors in the two screenshots above.

Tool 2: To find a suitable value, run test/contrast.cxx. Field #255 is a test field you can use to find contrast values. Enter the background color value by using the embedded color chooser (screenshot below). The default is (0xff, 0xff, 0xff) which is the background color of the Rose Gold theme, so you shouldn't need to change it for this one. There are different (darker) background colors in the "Greybird" theme though.



The three color sliders are intended to be used for the foreground (text) color. In this case we use the chosen selection color to calculate its contrast with given background color:



You should also set the radio button to "CIELAB".
The "label color" displays the chosen values in hex notation and the "labelsize" slider can be used to increase the font size. I used 19 or 20.



Whenever you enter new values you can use the "level" slider to see when the color in field "255" changes (fg, black, white). In the test case level 55 was the highest value that still displayed a blue label "255", i.e. level 55 would give you a blue radio button on white background, using the selection color given above.

You can also click on the field "255" to produce output in the text area below the widgets where 'fg' and 'bg' are the foreground and background colors, and 'lfg' and 'lbg' are the calculated luminance values. Finally the result of fl_contrast() is shown as one of 'fg', 'BLACK', or 'WHITE'. 'fg' is what you want to see.



Feel free to test the "legacy" mode as well for comparison. You'll see that some of the fields will have insufficient contrast. For comparison it's useful to switch between CIELAB and LEGACY. CUSTOM is not implemented, it would be available for users like you... ;-)

All the other colored fields in the contrast test program are those of the FLTK color cube (colors 0 - 255), and the main purpose of this test program was to find out how a particular text color set by the "gray" or color (R,G,B) sliders contrasts with all the 256 background colors.

After all this is a subjective "trial and error" process. I wanted to demonstrate how the given selection colors of the four themes in question could be modified (made darker) to be "acceptable" for the new fl_contrast() algorithm w/o changing the hue. You may find lighter values (closer to your original theme colors) if you test and eventually set fl_contrast_level() lower, supposedly in the range 52 to 54, or even 50. It's up to you...

I got the impression that you have full control over all colors of the chosen themes, and if you control fl_contrast_level() you should be able to achieve the best overall results that are as close as possible to the given theme colors - even if modifying the colors would make them kinda different from the original themes they came from.

I hope this helps. I would appreciate to hear (read) from you what the outcome of your development is.

[Daniel Harding]

@Albrecht Fantastic, thank you for the in depth explanations. I will tinker with all of this soon.

(You're absolutely right that I am free to tweak my themes, I was just first exploring options that involve FLTK making fewer astonishing changes. I very well may end by deciding to slightly tweak the selection color of these 4 themes.)

[Daniel Harding]

On Friday, May 10, 2024 at 11:48:31 AM UTC-5 Albrecht-S wrote:

I hope this helps. I would appreciate to hear (read) from you what the outcome of your development is.

test/contrast is very amusing to watch while dragging the sliders, especially the "gray" slider.

I settled on lowering the contrast level to 50 with the new/default contrast mode, and using slightly lighter shades than your suggestions/examples, particularly due to Aero/Metro.

I'm very satisfied with the end result. Thanks.

It's nice to so quickly be able to see exactly how much difference there is between a contrast level of 50 and 55.

[Albrecht Schlosser]

On 5/11/24 04:24 Daniel Harding wrote:

On Friday, May 10, 2024 at 11:48:31 AM UTC-5 Albrecht-S wrote:

I hope this helps. I would appreciate to hear (read) from you what the outcome of your development is.

test/contrast is very amusing to watch while dragging the sliders, especially the "gray" slider.

... and the "level" slider.

I settled on lowering the contrast level to 50 with the new/default contrast mode, and using slightly lighter shades than your suggestions/examples, particularly due to Aero/Metro.

OK, thanks, that's good to know.

I'm very satisfied with the end result. Thanks.

Great, and welcome.

It's nice to so quickly be able to see exactly how much difference there is between a contrast level of 50 and 55.

Yeah, after all this is or will be the first release of this new algorithm. Fine tuning with fl_contrast_level() is a user option intended to get feedback or to react on issues w/o having to change the FLTK code and to release a new patch version.

@Daniel: what do you think, would you suggest to lower the default value to 50 or anything between 50 and 55? What is your impression from playing with the contrast tool? Is 55 maybe too aggressive? Please try to answer this from a neutral (FLTK dev and user) view, not biased on your specific problem.

[Daniel Harding]

On Saturday, May 11, 2024 at 12:53:26 PM UTC-5 Albrecht-S wrote:

Yeah, after all this is or will be the first release of this new algorithm. Fine tuning with fl_contrast_level() is a user option intended to get feedback or to react on issues w/o having to change the FLTK code and to release a new patch version.

@Daniel: what do you think, would you suggest to lower the default value to 50 or anything between 50 and 55? What is your impression from playing with the contrast tool? Is 55 maybe too aggressive? Please try to answer this from a neutral (FLTK dev and user) view, not biased on your specific problem.

This is really difficult. I've been playing with the contrast tool a lot and I honestly, genuinely think the contrast level is best at 39.

That may sound dramatic, but here are some of my reasons:

Pure red text on any background is *impossible* at level 55. It requires a level of mid to low 40's or lower before red text is "allowed" on a fair number of white and black backgrounds (which I really think should be allowed).

Pure white text on a pure magenta background isn't even allowed until level 39. This one is shocking to me because I think white text on magenta looks a smidge better than black text on magenta (but they are almost equally as good).

Most importantly: I believe FLTK's role in "contrast enforcement" should be to prevent things that are "very obviously foolish". FLTK should fix the poorest of contrasts, but for anything that could make you say "well that looks okay either way" then FLTK should not intervene.

If FLTK too often says "you can't use that foreground color with that background color", then that leaves the programmer saying "ugh, but I want to!" too often.

IMHO, all the "important" cases where FLTK should intervene are still handled at level 39, while still respecting the freedom of the application programmer.

P.S. I noticed that black text fared better at a level around 50, but white text fared better around 35. I think 39 strikes the best balance between them, but it's really really difficult.

P.P.S. I wonder if the Cielab algorithm can be rebalanced such that ~39 becomes the new 50, so that the default can remain as 50 while achieving the less aggressive behavior that I think is appropriate.

[Daniel Harding]

But of course as soon as I send that message, I take another look at black text on any background and I can't ignore how black text feels like it needs a level of at least 54 or higher..

[Daniel Harding]

(Sorry for the triple post, but) So all-in-all, I think 55 is a fine default because black text looking good is important. And anyone working on a particularly colorful app can lower the level if needed.

But long term, I think it would be ideal if it can be tweaked such that black text still looks good, but colorful combinations aren't tampered with so much unless really necessary.

[Albrecht Schlosser]

On 5/12/24 17:41 Daniel Harding wrote:

On Saturday, May 11, 2024 at 12:53:26 PM UTC-5 Albrecht-S wrote:

Yeah, after all this is or will be the first release of this new algorithm. Fine tuning with fl_contrast_level() is a user option intended to get feedback or to react on issues w/o having to change the FLTK code and to release a new patch version.

@Daniel: what do you think, would you suggest to lower the default value to 50 or anything between 50 and 55? What is your impression from playing with the contrast tool? Is 55 maybe too aggressive? Please try to answer this from a neutral (FLTK dev and user) view, not biased on your specific problem.

This is really difficult.

I agree wholeheartedly.

I've been playing with the contrast tool a lot and I honestly, genuinely think the contrast level is best at 39.

That's surprising, but less than one might think (see below).

That may sound dramatic, but ...

OK, good arguments elided at this point ...

Most importantly: I believe FLTK's role in "contrast enforcement" should be to prevent things that are "very obviously foolish". FLTK should fix the poorest of contrasts, but for anything that could make you say "well that looks okay either way" then FLTK should not intervene.

Very, very good point! Honestly, that kind of well-balanced arguments are what I expected from you. Very much appreciated!

After all, the "contrast level" is the point of *sufficient* contrast. We could define a delta of 40 (or 50) as sufficient, rather than 55, and not change the foreground color at all if that is the case. That would, for instance, correspond to a contrast level of 40 (or 50) for the CIELAB algorithm.

If FLTK too often says "you can't use that foreground color with that background color", then that leaves the programmer saying "ugh, but I want to!" too often.

IMHO, all the "important" cases where FLTK should intervene are still handled at level 39, while still respecting the freedom of the application programmer.

Well, IIRC, there were some notes from Andy, the author of APCA, that the flip point of black or white text lies somewhere between 40 and ... (I don't remember, maybe ...) 46? Actually we have two decisions to make:

1. is the contrast sufficient? The question is how to define "sufficient", that's the hard decision.

2. if not, select either black or white (that's the easy decision).

P.S. I noticed that black text fared better at a level around 50, but white text fared better around 35. I think 39 strikes the best balance between them, but it's really really difficult.

Again, I agree, it's really difficult.

P.P.S. I wonder if the Cielab algorithm can be rebalanced such that ~39 becomes the new 50, so that the default can remain as 50 while achieving the less aggressive behavior that I think is appropriate.

I would rather lower the default level to 50 or maybe 52 than defining yet another transformation. The difference between white (luminance 100%) and black (0%) is 50% which make this a good point. Imagine a foreground color with luminance 50% and its contrast to a similar bright background color, what should you do? The contrast (delta) to both black and white would be 50, therefore 50 might be the best flipping point. (?)

Replying to your follow-up mails:

> But of course as soon as I send that message, I take another look at black text on any background and I can't ignore how black text feels like it needs a level of at least 54 or higher.

Well, exactly that is the problem. Different scenarios may be resolved best by different contrast levels. Sigh.

> So all-in-all, I think 55 is a fine default because black text looking good is important. And anyone working on a particularly colorful app can lower the level if needed. But long term, I think it would be ideal if it can be tweaked such that black text still looks good, but colorful combinations aren't tampered with so much unless really necessary.

That would be when we integrate the 'context' argument, I guess. If you read the articles linked by Andy, "spatial frequency" is the point. This would automatically reduce the "aggressiveness" (contrast level) of the algorithm when (a) larger fonts or (b) other objects like check marks or radio buttons are involved, but I don't want to attack this in 1.4.0 because of likely unwanted effects and lack of time to make a **good** implementation.

Meanwhile I'll think about lowering the default contrast level of the new (CIELAB) algorithm from 55 to 50-53 or something like that. This might be a good (better) compromise for now, and as you said, users can always change the contrast level as they like.

Thank you very much for your input.

[Albrecht Schlosser]

Well, I'm coming back to fl_contrast() and fl_contrast_level() ...

On 5/12/24 17:41 Daniel Harding wrote:

On Saturday, May 11, 2024 at 12:53:26 PM UTC-5 Albrecht-S wrote:

Yeah, after all this is or will be the first release of this new algorithm. Fine tuning with fl_contrast_level() is a user option intended to get feedback or to react on issues w/o having to change the FLTK code and to release a new patch version.

@Daniel: what do you think, would you suggest to lower the default value to 50 or anything between 50 and 55? What is your impression from playing with the contrast tool? Is 55 maybe too aggressive? Please try to answer this from a neutral (FLTK dev and user) view, not biased on your specific problem.

This is really difficult. I've been playing with the contrast tool a lot and I honestly, genuinely think the contrast level is best at 39.

Finally this was my decision: default fl_contrast_level() for the new CIELAB contrast algorithm is now 39.
See commit 9820d9f5559c9afd17b8d3b64285e763a75daa98

Note that I will document the new values later, the docs have not yet been updated.

That may sound dramatic, ...

Most importantly: I believe FLTK's role in "contrast enforcement" should be to prevent things that are "very obviously foolish". FLTK should fix the poorest of contrasts, but for anything that could make you say "well that looks okay either way" then FLTK should not intervene.

Rationale of my latest decision:

(1) While developing and testing the new algorithm I had over time lost the focus on *sufficient* contrast. Honestly, this was always the question I could not answer clearly: what is sufficient contrast? Meanwhile I came to the conclusion: if you can *read* the text, then the contrast is *sufficient*.

(2) There may be some combinations of foreground (text) color and background color that are not well readable, but so be it. As you, Daniel, wrote above, FLTK should not intervene unless the combination is really foolish, i.e. if the text is definitely not readable.

(3) IIRC I read elsewhere that the contrast in the CIELAB calculation can be considered sufficient if it is somewhere in the range 36 to 45 or similar. There is no exact point or value. Contrast perception depends on other factors as well: dark text on light background or the opposite, font size and weight (spatial frequence), etc.. Hence the exact value can't be determined.

(4) Last but not least: our old ("LEGACY") algorithm evaluated 99/255 = 38.8%  as "sufficient". Even if the calculation of the "lightness" (see docs of fl_lightness) was not correct which cause the bad behavior, the idea behind the value was good. Thus, using 39 in the new algorithm is the best compromise for backwards compatibility.

That said, there are some color combinations where the legacy algorithm appears to be "better" and in some cases the old algorithm returns FL_WHITE where the new CIELAB algorithm returns FL_BLACK and vice versa. But these are exceptions to the rule that the new algorithm is better in most cases.

For further tests I added a new feature to the contrast test program: the button RC (Random Color) creates a random text color, as its name and the tooltip say. This can be used to test a lot of combinations (256 per click) to see whether the text is readable - and readable is the only criterion that should be applied. Although I found some "bad" contrast values, the text was always readable.

@Daniel: Another positive effect of this change is that all themes in question of your application except "Greybird" work as expected with the new value 39 and the old selection colors. "Greybird" needs either a slightly darker selection color or fl_contrast_level() needs to be lowered to 36 which is IMHO not advisable in general. I verified this by using the project you linked before: https://github.com:Rangi42/polished-map.git which I managed to build with FLTK 1.4 with some minor changes.

Many thanks for your constructive and helpful arguments that led me back to thinking about "sufficient contrast" more properly. The new behavior is now more like the old algorithm but avoids some very low contrast combinations by using a better lightness calculation (perceived contrast).

P.P.S. I wonder if the Cielab algorithm can be rebalanced such that ~39 becomes the new 50, so that the default can remain as 50 while achieving the less aggressive behavior that I think is appropriate.

This could be done, but I don't think it's necessary. Every algorithm has its own fl_contrast_level() and the values are defined in the context of the specific algorithm. This is more flexible and new algorithms might have different needs anyway. For the CIELAB algorithm the given value can be interpreted as the contrast between the two colors on a scale from 0 to 100 (%). As written above, a contrast value of about 40% can be considered sufficient, even if it is not always "good".

I'm still open for suggestions and I always appreciate feedback. Thanks.

[Bill Spitzak]

The intention of fl_contrast was to fix combinations that were totally unreadable, in particular to fix where both colors are the same. The original purpose was so that if you made the highlight color black it would reverse-video the selected text (for the default text color was black and the background white), and thus avoid the need for another color (the "highlighted text color") and also to make it possible to make colored text selectable. I would certainly aim for a function that does not alter color combinations where it is physically possible to read the text, even if squinting is needed.

--
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 fltkgeneral...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/c547a6a4-a186-459f-b335-506d533139a9%40aljus.de.

[Albrecht Schlosser]

On 5/16/24 21:29 Bill Spitzak wrote:

The intention of fl_contrast was to fix combinations that were totally unreadable, in particular to fix where both colors are the same. The original purpose was so that if you made the highlight color black it would reverse-video the selected text (for the default text color was black and the background white), and thus avoid the need for another color (the "highlighted text color") and also to make it possible to make colored text selectable. I would certainly aim for a function that does not alter color combinations where it is physically possible to read the text, even if squinting is needed.

Thanks, Bill, I always appreciate when you explain details and intentions of the existing code. What you describe is IMHO what we have now with the mentioned commit. It is AFAICT compatible with the intention of the old fl_contrast() function (as you described above) but avoids some unreadable border cases where the old algorithm was too "simple" (and incorrect).

On Thu, May 16, 2024 at 12:19 PM 'Albrecht Schlosser' via fltk.general <fltkg...@googlegroups.com> wrote:

Well, I'm coming back to fl_contrast() and fl_contrast_level() ...

...