Adjust FlatLafDark tab-switcher and selection foreground colors

[mbien]

• use context menu colors for tab switcher popup
• set selection foreground to white if contrast is not sufficient
• slightly brighten foreground color for more contrast

before:

after:

before:

after:

slightly higher contrast gives more options to use faded text for less important information, e.g #7930 (comment)

[neilcsmith-net]

Selection foreground should not be hardcoded - it's dynamic based on accent colour, and on my chosen accent is dark. If there's a need for more contrast, take a look at upstream and consider a suitable override - eg. https://github.com/JFormDesigner/FlatLaf/blob/main/flatlaf-core/src/main/resources/com/formdev/flatlaf/FlatDarkLaf.properties#L48

I wouldn't change just the popup switcher either, as these default to combobox colours. I'm curious why combobox popups and popup menus are different colours in FlatLaf Dark but not in FlatLaf Light. Personally I'd look to change all the popups.

See also JFormDesigner/FlatLaf#762

[eirikbakke]

There should probably be an even bigger contrast between disabled and enabled menu items. These (even with your increased foreground brightness adjustment) are too similar:

In my own NetBeans Platform app I use a much brighter foreground color on dark mode:

Maybe somewhere in between could work for NetBeans.

[neilcsmith-net]

@eirikbakke agreed, and have been toying with similar my platform applications. Although I also think, like the linked upstream issue, that this is partly about darkening some backgrounds to increase contrast. The accessibility tool links in that issue are useful either way.

I think this is something for NB26 with more time to consider and test against the various UI elements and configuration options.

[mbien]

In my own NetBeans Platform app I use a much brighter foreground color on dark mode:

so do I (for the IDE i use @foreground=#d1d1d1 and darken the accent color for selections - this fits well together with white selection foreground), but I didn't want to completely change the theme. Those are just adjustments.

Selection foreground should not be hardcoded - it's dynamic based on accent colour

I am not sure about this. It is the setting for the dark theme, white text works for the given accent colors. I don't know how to darken accent colors for dark themes without causing an endless loop in the parser (maybe we should just add darker variants?). If it works better than the computed color -> its good enough for me.

(but darkening the accent color for selections by 10-20% would be the missing ingredient here)

this is the computed NB 24 value

I wouldn't change just the popup switcher either, as these default to combobox colours.

comboboxes look fine to me and are far less complex than the tab switcher which has 2 different kinds of decorators iteracting with each other.

[mbien]

@selectionBackground = if(@accentColor, darken(@accentColor,15%), @accentBaseColor)

found a way to darken the selection background color without breaking the parser when its unset (which is the default).

[neilcsmith-net]

Given the user can select any colour they want as the accent colour, that won't work. Dark text for selected items is the right approach there. Changing the selection foreground to a fixed colour is a no go.

If you want to fix just the tab popup for now, do that, although is there a reason to mix $MenuItem and $List values - just $MenuItem makes sense?

The contrast accessibility issues (eg. with comboboxes) are covered in the linked upstream issue. Changing foreground to #cccccc is just about a pass and improvement.

[mbien]

Given the user can select any colour they want as the accent colour, that won't work.

it already does work for the editor tab renderer which uses a darkened version of the accent color!

its already used today in NB 24. I don't change the accent color, I change the selection bg color

15% darkened selection bg + white selection fg

Dark text for selected items is the right approach there.

here a purple theme I found for cinnamon:

this looks familiar, no?

NB with PR applied for comparison:

[neilcsmith-net]

it already does work for the editor tab renderer which uses a darkened version of the accent color!

Yes, I know, I put it there. And the key difference is that it's not rendering text on top of the accent colour.

I'm not in favour of darkening the accent colour in the menus and tree. Kind of defeats the point of being able to set it.

Even if you do darken it, you must still set the foreground colour based on the selection background. For the ultimate test try setting the accent colour to white. Everything should still work. (aside - there seems to be something in the tree code that forces the foreground to black, but not in the menu).

[eirikbakke]

Even if you do darken it, you must still set the foreground colour based on the selection background. For the ultimate test try setting the accent colour to white. Everything should still work.

I wouldn't expect (or require) white to work as an accent color.

[neilcsmith-net]

@eirikbakke it works now! It was purely to demonstrate pale accent colours. Although I quite like it, now, actually. It would at least be good not to break things that work!

There's nothing stopping adjusting the upstream code to something like (perhaps not as extreme as) -

@selectionForeground = contrast(@selectionBackground, #000, #fff, 25%)

[mbien]

updated it to set the color based on contrast, similar method of the FlatLaf defaults.

For the ultimate test try setting the accent colour to white. Everything should still work.

this is now somewhat comparable to how NB's html renderer works (check branch labels which are flipped to white automatically):

[mbien]

please test using the dev build of this PR or simply by setting the properties. Screenshots won't tell the whole story.

[mbien]

@eirikbakke the reason why I didn't go brighter than that is because the default dark editor color scheme is also low contrast. Brighter would move the attention away from the code. This is also only intended to adjust the theme slightly without doing larger changes.

The theme / color scheme I currently use for NB does have higher contrast for the editor too (font is also a bit thicker), so making the default text brighter, is less of a problem there.

(note: focus is in the edtor which lets the tree render the selection with a secondary color, the used accent color is fairly bright orange)

[eirikbakke]

the reason why I didn't go brighter than that is because the default dark editor color scheme is also low contrast. Brighter would move the attention away from the code.

Yeah I think that makes sense. Code and sidebars have to remain balanced/similar.

And this is kind of a low-contrast theme, for users without a lot of sunlight in the room.

[mbien]

If you want to fix just the tab popup for now, do that, although is there a reason to mix $MenuItem and $List values - just $MenuItem makes sense?

@neilcsmith-net I don't remember, I thought it was because of the "underline menu selection mode" and because the switcher doesn't suppor it - but it works fine -> changed everything to $MenuItem

[mbien]

I'm not in favour of darkening the accent colour in the menus and tree. Kind of defeats the point of being able to set it.

@neilcsmith-net I checked and the default flatlaf dark provided shade of blue is dark enough to work well with the adjustments, while essentially all other NB provided presets are hardly useable.

gong to remove the list/tree/table selection bg adjustment since it still gives a decent out-of-the-box setting without it - until the accent is changed.

But overall I don't share the sentiment that selection colors must have the same brightness as other usages, for example radio button highlghts or tab lines. Big filled areas != small component decorations due to the difference in footprint. One can blind you on dark themes, the other usually doesn't.