Use the gray color for all abstract classes

[MewPurPur]

This is meant as a small quality of life thing and something that should be "obviously better", so I haven't made a proposal for it yet. The changes in this PR are as follows:

• Gray out all abstract class icons that currently exist
• In Create Dialog and Search Help, use either NodeDisabled.svg for abstract nodes that don't have icons, or the newly added ObjectDisabled.svg for abstract non-node objects that don't have icons

I think this gives a pretty good result overall:

• You can more easily tell if a class is abstract from its icon

• Virtual objects no longer appear like disabled nodes

• Search Help now aligns with what you see in the creation dialog.

(CollisionShape2D and CollisionShape3D currently appear with a white Object icon)

[fire]

As part of the usability team I really like the concept of greying out the images. Did not technical review.

[Calinou]

Tested locally, it works as expected.

[MewPurPur]

Missed something.

[MewPurPur]

Applied this also to the inspector.

^ Light theme in case you're worried about contrast.

[akien-mga]

I'm a bit concerned about changing the base color of these icons, as the color is meant to reflect the inheritance (red icons all inherit from Node3D, etc.). I think it can make sense to modulate the icon for abstract classes programmatically for the Create New Node dialog, but I'd keep them in a shade that conveys the inheritance, and not modify the base SVGs, so it doesn't impact e.g. the icons visible in the Editor Help or Inspector.

[YuriSizov]

To add to that, we may sneakily use some of these icons for other visual elements where it can be important to preserve the color to convey the context/meaning.

[MewPurPur]

This was actually my initial idea. I'm not against this per-se, but to be devil's advocate:

• Doing this programmatically might lead to counterintuitive results. The main thing is that, for example, to turn the light color into a disabled color, if our programmatic rule is to keep half of the original color, then we have to modulate not with #808080, but rather a really dark color #1f1f1f. I've not tested this though.
• It increases the amount of colors significantly, and with resources, these colors will often be used exactly once. Seeing an unfamiliar color might become unclear if it's something abstract or something you don't know. The color availability is reduced. It increases the risk of things blending in backgrounds.
• Less association between the 20% of abstract classes that have icons, and the 80% that are missing icons and so are using a grayed out node/object icon.

So I'll resist it a little for now, so we can have some discussion about these pros and cons.

@YuriSizov I don't get what you mean.

[YuriSizov]

I don't get what you mean.

These icons may be used for things other than node types in the editor. And in those cases it is very likely important that icons have their assigned color palette, as Akien mentions.

[TheYellowArchitect]

Doing this programmatically might lead to counterintuitive results. The main thing is that, for example, to turn the light color into a disabled color, if our programmatic rule is to keep half of the original color, then we have to modulate not with #808080, but rather a really dark color #1f1f1f. I've not tested this though.
It increases the amount of colors significantly, and with resources, these colors will often be used exactly once. Seeing an unfamiliar color might become unclear if it's something abstract or something you don't know. The color availability is reduced. It increases the risk of things blending in backgrounds.
Less association between the 20% of abstract classes that have icons, and the 80% that are missing icons and so are using a grayed out node/object icon.

Why have them programmatically? It's basically 3 colors. There is red (3D), green(Control), blue(2D) basically RGB. If the color isn't at least a shade of the aforementioned 3 colors, as Akien mentioned above, gray degrades the colorcoding intuitiveness.

[MewPurPur]

Idea: 3 non-programmatical 60% gray colors for GUI, 2D, and 3D. Gray for white icons and everything else

[akien-mga]

I'm pretty sure we can find a modulate value that makes it look desaturated without having to change the icons.

[MewPurPur]

If we have a custom color for abstract 2D, 3D, and GUI nodes, then I'd prefer to have it in the icons so their appearance is consistent everywhere you see that icon. IMO the only good point was about their color communicating something about their inheritance, and this would solve it.

[MewPurPur]

Do you like this? It's on the icons. I'm not that sure about it but I guess it's fine

[Zireael07]

Related: #794

We shouldn't be using solely color to convey inheritance

[MewPurPur]

I saw that proposal, but my personal conclusion was as follows:

• The problem was always hypothetical, not a report from a colorblind person. In fact, no type of color blindness other than monochromia (extremely rare) should struggle to tell apart red and blue.
• White and green are problematic, but that's only a problem with Node, Node2D, Node3D, Control.

So then we're left with 10-15 nodes that share the same icon between blue and red. It seems like an obvious conclusion that a different shape improves usability, but I beg to differ:

• As aforementioned, colorblind users don't actually struggle to tell apart blue and red.
• Our icons are meant to work in 16x16. Flat icons are very easy to read and understand, but all suggestions that people updooted were for fancy 3D effects would be difficult to read in practice.
• The suggestion that didn't involve 3D effects had arbitrary pillars, like blue=masculine, red=feminine. People didn't like that.

Because of this, I only appreciate a change of 3D icons when there's an important functional difference it tries to communicate (e.g. CollisionPolygon3D).

NavigationObstacle and NavigationAgent use different shapes for their 2D and 3D versions' icons, even though they don't need to, and I think this shows the shortcomings of this whole idea. NavigationAgent3D is painful to recognize at small scales because it has this fancy 3D effect, whereas the simple flat NavigationAgent2D is insta recognizable.

So yes, I think improving this for monochromia people makes it way too much worse for everyone else for it to be worth it IMO.

And besides, just because colorblind people exist, doesn't mean we shouldn't use colors for usability. It rather means we shouldn't rely on them and consider them more of a last resort, when nothing else works - consider syntax highlighting. And I don't think anything else works here.

[YuriSizov]

The dimmed colors version looks nice, assuming it's done with modulation.

[MewPurPur]

No, it's not modulation, it's three new colors in the editor themes that are 60% gray and 40% green/red/blue.

I don't really get why we'd want to use modulation, to me it seems better to be consistent everywhere with how we display these classes. It's not entirely gray, so it won't look disabled e.g if it's on a button - so I don't see a problem

[Zireael07]

It rather means we shouldn't rely on them and consider them more of a last resort,

What I said, just in different words ;)

[MewPurPur]

Not really, because I'm saying essentially "we should use solely color to represent inheritance, because every other way is worse and blue and red are easy to tell apart for everyone"

[MewPurPur]

Next take: The colors used are a bit different, in a way that should be distinct enough from both plain gray and the node color. No modulation is used, I didn't get any nice colors from applying modulation indiscriminately. It would've also forced a bunch of light vs dark theme checks, so I think it's much nicer to just have 3 dedicated "abstract" colors that sit between gray and the node color (in my case, obtained by getting 1/3 gray, 2/3 node color, and darkening/lightening by 15%)

I changed EditorNode's get_class_icon() function to get at the core of the issue, as there were more places listing nodes than just the 3 I addressed. Afaik now it looks good everywhere. The new get_class_icon() uses my logic as a default fallback for missing icons, and provides a way to use a different type of fallback - only used by EditorHelp, afaik.

[aaronfranke]

I like the colors in the latest version of the PR. I do wonder if it should be slightly grayer, but now it is easy to tell what dimension these nodes are from.

[aaronfranke]

I just remembered I had already done something similar with the colors in Node1D:

I used faded cyan for CollisionObject1D. So, yeah, I like the colors in this PR.

[MewPurPur]

I opted for a bit of desaturation because while cyan is a bright color, our 2D blue is darker even than the 50% gray, so abstract blue would have looked bad in some places (as most of our interface is blueish)

We don't have abstract 2D classes icons currently, but it might become a thing 🤷

[Calinou]

How it looks with the latest revision of this PR:

Before	After

PS: Scrollbar, Slider and Separator abstract classes are lacking icons. Maybe we can use diagonally rotated variants like we did for BoxContainer? Either way, that would be for a future PR.

[YuriSizov]

See above.

[MewPurPur]

@Calinou Was already in my plans, I just wanted to finally determine what'll happen with abstract node icons.

[MewPurPur]

This push should resolve the suggested changes.

[YuriSizov]

The implementation looks great now!

I've come around to the idea of hardcoding desaturated colors, so I think we can go ahead with this.

[akien-mga]

Thanks!

[aaronfranke]

With this PR, descendants of types without explicit icons are missing icons. I think this is a bug. Before:

After:

[YuriSizov]

With this PR, descendants of types without explicit icons are missing icons.

Not entirely this PR's fault, but it did expose something. I'll make a fix.