Regression: Menu item highlight color hardcoded in 4.0 #113943

New Issue

Ludvik Koutny · 2023-10-19T17:02:47+02:00

Ludvik Koutny commented

2023-10-19 17:02:47 +02:00

System Information
Operating system: Windows-10-10.0.22621-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 2080 Ti/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 537.13

Blender Version
Broken: version: 4.0.0 Beta, branch: blender-v4.0-release, commit date: 2023-10-18 20:17, hash: e11f031d62cc
Worked: 3.6

Short description of error
In Blender 4.0, menu item highlight color can not be customized, and is hardcoded instead.

Exact steps for others to reproduce the error

In Blender 4.0, attempt to customize menu item highlight color.
Result: The color is hardcoded and can't be customized.
Expected: The color can be customized, as in 3.6.

**System Information** Operating system: Windows-10-10.0.22621-SP0 64 Bits Graphics card: NVIDIA GeForce RTX 2080 Ti/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 537.13 **Blender Version** Broken: version: 4.0.0 Beta, branch: blender-v4.0-release, commit date: 2023-10-18 20:17, hash: `e11f031d62cc` Worked: 3.6 **Short description of error** In Blender 4.0, menu item highlight color can not be customized, and is hardcoded instead. ![3.6.png](/attachments/dbe925c6-9c3c-498f-83d2-2306221a45cd) ![4.0.png](/attachments/85868654-d607-448a-a587-9cf1cce2257e) **Exact steps for others to reproduce the error** 1. In Blender 4.0, attempt to customize menu item highlight color. Result: The color is hardcoded and can't be customized. Expected: The color can be customized, as in 3.6.

4.0.png

109 KiB

3.6.png

118 KiB

Ludvik Koutny added the

labels 2023-10-19 17:02:47 +02:00

Harley Acheson commented

2023-10-19 20:17:08 +02:00

The state you are showing is not a "selected" state but a "hover" state. The hover highlight has never been themeable.

For 4.0 we needed separate "hover" and "selected" states so that we could show selected items while also showing a hover highlight, for things like enum menus. This meant having to change from using the selected color for dropdown menu hover and instead show it as consistent with other menu hover items. Without doing this the difference between a dropdown menu and an enum menu was jarring and confusing.

The state you are showing is not a "selected" state but a "hover" state. The hover highlight has never been themeable. For 4.0 we needed separate "hover" and "selected" states so that we could show selected items while also showing a hover highlight, for things like enum menus. This meant having to change from using the selected color for dropdown menu hover and instead show it as consistent with other menu hover items. Without doing this the difference between a dropdown menu and an enum menu was jarring and confusing.

Ludvik Koutny commented

2023-10-19 20:23:03 +02:00

The state you are showing is not a "selected" state but a "hover" state. The hover highlight has never been themeable.

For 4.0 we needed separate "hover" and "selected" states so that we could show selected items while also showing a hover highlight, for things like enum menus. This meant having to change from using the selected color for dropdown menu hover and instead show it as consistent with other menu hover items. Without doing this the difference between a dropdown menu and an enum menu was jarring and confusing.

It is themeable in 3.6, so this is a regression. The biggest issue is that the color is just hardcoded gray or black, so it works very poorly with non gray themes. If we keep adding more and more harcoded colors then what is the point of having theme editor in the first place.

For example look just how bad it looks with OneDark style themes:

It is not true that the hover highlight has never been themeable. It was up until 4.0.
Theres no excuse not to have it themeable given how ridiculously granular theme editor is.

Imagine the frustration of someone spending hours to craft the perfect theme and then realizing there's a few seemingly arbitrarily chosen UI elements that just have hardcoded color. How can we possibly excuse having hundreds unique color swatches in the theme editor but at the same time hardcoding colors. It almost feels as taunting.

If there's a need for highlight of a selected enum menu item, then switch it the other way around. The selected item having hardcoded color overlay is way lesser evil then not being able to theme the hover highlight, because the hover highlight is something user will come in contact way more often, so it has no business looking ugly.

There have been just way too many UI visual design quality regressions in 4.0 already.

OR:
Let's use Inner color for the hover highlight. Every single theme bundled with Blender has Inner color either set to Alpha 0, or set to exact same color as the menu background, because apparently no one wants the menu items look like buttons:

EDIT:
WAIT! It DOES use the inner color, even with alpha 0!

Ok, so this can be closed, but it should be documented somewhere that the menu item color is not hardcoded, but instead "Inner" color is used now.

> The state you are showing is not a "selected" state but a "hover" state. The hover highlight has never been themeable. > > For 4.0 we needed separate "hover" and "selected" states so that we could show selected items while also showing a hover highlight, for things like enum menus. This meant having to change from using the selected color for dropdown menu hover and instead show it as consistent with other menu hover items. Without doing this the difference between a dropdown menu and an enum menu was jarring and confusing. It is themeable in 3.6, so this is a regression. The biggest issue is that the color is just hardcoded gray or black, so it works very poorly with non gray themes. If we keep adding more and more harcoded colors then what is the point of having theme editor in the first place. For example look just how bad it looks with OneDark style themes: ![image](/attachments/80cde6e1-3da4-4999-b7c8-accf921f78f4) 1. It is not true that the hover highlight has never been themeable. It was up until 4.0. 2. Theres no excuse not to have it themeable given how ridiculously granular theme editor is. Imagine the frustration of someone spending hours to craft the perfect theme and then realizing there's a few seemingly arbitrarily chosen UI elements that just have hardcoded color. How can we possibly excuse having hundreds unique color swatches in the theme editor but at the same time hardcoding colors. It almost feels as taunting. If there's a need for highlight of a selected enum menu item, then switch it the other way around. The selected item having hardcoded color overlay is way lesser evil then not being able to theme the hover highlight, because the hover highlight is something user will come in contact way more often, so it has no business looking ugly. There have been just way too many UI visual design quality regressions in 4.0 already. OR: Let's use Inner color for the hover highlight. Every single theme bundled with Blender has Inner color either set to Alpha 0, or set to exact same color as the menu background, because apparently no one wants the menu items look like buttons: ![image](/attachments/dbbaeea5-11d5-4813-8883-4c4d5681811b) EDIT: WAIT! It DOES use the inner color, even with alpha 0! ![image](/attachments/04bf1c26-2148-483d-91ed-5372b24cb8c5) Ok, so this can be closed, but it should be documented somewhere that the menu item color is not hardcoded, but instead "Inner" color is used now.

image.png

185 KiB

image.png

84 KiB

image.png

292 KiB

Pratik Borhade commented

2023-10-20 06:56:35 +02:00

@Rawalanche hi, I think we already discussed about this: #112122 / #113009 / #112380

I think your suggestion was to use complete "inner" color for highlighting the hovered item instead of blending the color.

@Rawalanche hi, I think we already discussed about this: #112122 / #113009 / https://projects.blender.org/blender/blender/pulls/112380 I think your suggestion was to use complete "inner" color for highlighting the hovered item instead of blending the color.

Pratik Borhade added

Module

User Interface

Status

Needs Info from Developers

and removed

Status

Needs Triage

labels 2023-10-20 06:56:53 +02:00

Ludvik Koutny commented

2023-10-20 10:07:34 +02:00

@Rawalanche hi, I think we already discussed about this: #112122 / #113009 / #112380

I think your suggestion was to use complete "inner" color for highlighting the hovered item instead of blending the color.

No, those were separate issues:
First issue was that the selected menu item color was linked to the frozen text color
Second one was that the selected menu item color had hardcoded color modification, making it brighter than the selected color.
This issue is about the hover color not using the same color swatch as it did in 3.6, and @Harley explained why

But you can close this. The color is not hardcoded but now uses Inner color, which is just not mentioned/documented anywhere. That's what caused the confusion.

> @Rawalanche hi, I think we already discussed about this: #112122 / #113009 / https://projects.blender.org/blender/blender/pulls/112380 > > I think your suggestion was to use complete "inner" color for highlighting the hovered item instead of blending the color. No, those were separate issues: First issue was that the selected menu item color was linked to the frozen text color Second one was that the selected menu item color had hardcoded color modification, making it brighter than the selected color. This issue is about the hover color not using the same color swatch as it did in 3.6, and @Harley explained why But you can close this. The color is not hardcoded but now uses Inner color, which is just not mentioned/documented anywhere. That's what caused the confusion.

Pratik Borhade commented

2023-10-20 10:59:10 +02:00

ok, closing then.

Pratik Borhade closed this issue

2023-10-20 10:59:13 +02:00

Blender Bot added

Status

Archived

and removed

Status

Needs Info from Developers

labels 2023-10-20 10:59:15 +02:00