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.)
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]
Is it possible to customize this?
Thanks for any advice.
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?
if (fl_contrast(color, r) != color) { // ?? text color 'color' has not enough contrast... ??```
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 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.
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.
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: [image] And here are the themes in FLTK 1.4 with the new/default contrast function: [image]
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.
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?
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.
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.
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.
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 can't find commit 866a4a4fcb6c564b067cce38a90696645fab7c0e in the fltk repo or your fork of it.
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.
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 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?
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.
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).
This is now fixed in FLTK 1.4, current master: commit 79ddf2f2b854aac373123620b8c722f81f4fbdaa
Is there still anything I missed?
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
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:
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:
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.
I hope this helps. I would appreciate to hear (read) from you what the outcome of your development is.
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.
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.
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 ...
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.
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, ...
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.
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.
--
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.
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.
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() ...
...