Make the "Open Documentation" icon lighter to avoid making the option look disabled

[algorev]

Describe the project you are working on

A simple walkaround to familiarize myself with the engine.

Describe the problem or limitation you are having in your project

When you right-click on a node in the scene panel, a menu opens up with many options. among these options is the option to "Open Documentation", opening the documentation for that node.

The icon of this option is noticeably darker than the other options' icons, which gives the impression that the "Open Documentation" option is grayed out and/or disabled, when it is not the case.

This is arguably not a huge deal, just a very minor quality-of-life improvement that could probably be left as-is. It's just that it's confused me for a good amount of time before i understood that the option wasn't grayed out when beginning, and i imagine i might not be the only user in that situation.

Side note: a few icons in the menus seem to have varying brightness levels in general (e.g. the "copy node path" icon in the photo), and i don't know why. This is the single instance that i've found really confusing, so this is the one i'm opening an issue about.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Fix: make the option icon brighter, so that its brightness matches that of the other options. This way, it couldn't be mistaken as grayed out.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

Note: I'm not good at photo editing. Pardon the quality.

If this enhancement will not be used often, can it be worked around with a few lines of script?

It's one icon in the editor, it's not worth it.

Is there a reason why this should be core and not an add-on in the asset library?

It's one icon in the editor, it's not worth it.

[algorev]

I've looked around the icons in the engine repository and have been confronted with an enigma: all the icons seem to have the same base color, #e0e0e0. Knowing that, I can't explain why they have different brightnesses; they are the same color in the source files. At any rate, these differences don't seem like they are a design choice, more like a bug. The question is: where is the bug? Are the icons converted to raster when building the engine, and the error would be during the conversion, or are they rendered on the fly when running the app, and the bug would be in the ui? I'll look into it more.

[algorev]

According to the docs:

Because the editor renders SVGs once at load time, they need to be small in size so they can be efficiently parsed.

So the icons are rasterized at load time. Sounds like either the problem comes from there, either it comes from when the icons are shown.

[algorev]

I have looked up a bunch of files, but this gets way beyond my knowledge of how the program works. Given what I've said before, I'm not too sure my original proposal is relevant either. Maybe either another, more focused one or a bug report in the main repository?

[YuriSizov]

@algorev Icons have different perceived brightness due to two factors: they can use different opacities (and they do in this case) and they also are modulated to only have full brightness on hover, and modulation can highlight smaller differences.

Here's Remove.svg:

fill="#e0e0e0" fill-opacity=".99608"

And here's Help.svg:

fill:#e0e0e0;fill-opacity:.58824

Not sure why they use different opacities, but feel free to open a PR to set them to some common value (check other icons as well to make sure what's the best option).

[algorev]

Oh. You're right, i hadn't caught that. What is the reason for the different brightnesses in the design?

…

-------- Original Message --------

On 21 Jul 2021, 22:17, Yuri Sizov wrote: ***@***.***(https://github.com/algorev) Icons have different perceived brightness due to two factors: they can use different opacities (and they do in this case) and they also are modulate to only have full brightness on hover, and modulation can highlight smaller differences. Here's [Remove.svg](https://github.com/godotengine/godot/blob/master/editor/icons/Remove.svg): fill="#e0e0e0" fill-opacity=".99608" And here's [Help.svg](https://github.com/godotengine/godot/blob/master/editor/icons/Help.svg): fill:#e0e0e0;fill-opacity:.58824 — You are receiving this because you were mentioned. Reply to this email directly, [view it on GitHub](#3025 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AFQBJOFGRS4YGZA2IOKVYFLTY4TOXANCNFSM5AYHW6LQ).

[YuriSizov]

Like I've said above (but I guess edits don't magically show up in email notifications):

Not sure why they use different opacities, but feel free to open a PR to set them to some common value (check other icons as well to make sure what's the best option).

[algorev]

I see. I'll do that. Thanks for your help!

…

-------- Original Message --------

On 21 Jul 2021, 22:42, Yuri Sizov wrote: Like I've said above (but I guess edits don't magically show up in email notifications): > Not sure why they use different opacities, but feel free to open a PR to set them to some common value (check other icons as well to make sure what's the best option). — You are receiving this because you were mentioned. Reply to this email directly, [view it on GitHub](#3025 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AFQBJOGBKUCSHUADJFK5X4TTY4WMDANCNFSM5AYHW6LQ).