I’ve been making a theme more comfortable to work in for myself and noticed it’s impossible to change all those, and I want the colors to be consistent across other parts of the UI(and it’s kind of fun to tinker as well) and so I started playing with that, learned to compile Blender and I think I am starting to understand how it could be done. If I somehow managed to learn to do that well, would it be useful to share my changes? I am quite comfortable with Python and Blender’s Python API and I have been using Blender for over a decade, but I am completely new to C/C++ and Blender’s source code and development in general and so I am afraid my code might not be perfect(even though I am prepared to put as much effort into that as I am able). Would this be something worth pursuing? Is this even something that might be useful? How do I go about this?
I did create a right click select feature request for this recently, at the moment I only got negative feedback related to the biggest drawback - readability by other people when screenshots are shared. And that seems to be quite a valid argument against these colors being customizable. However I also know very well, that in reality these situations are not that common - people providing support with geometry nodes on Blender Stack Exchange always request .blend files shared, nobody wants to look at screenshots of hundreds of geometry nodes and try to figure out the problem anyway. Sharing just screenshots of the nodes when asking for help is now similar to sharing just screenshots of code when asking for help with coding. So… Personally I think this would be right. This is the whole idea of themes anyway - to make these things comfortable for one’s self, same as with node header colors, wireframe in the viewport or syntax highlighting in the text editor. All those things have same negative effects in screenshots if you think about it. It’s hard to look at 3d wireframe that one is not used to in screenshots as well and yet themes exist. So… I don’t know. I would like to hear what developers think about this.
OP already addresses that, saying we allow all kinds of customization that could just as be destructive to the legibility of information when shared with others, so this should be no different—I could make make buttons and text in the UI all black so no other person could tell what’s going on, but that would be my problem when I seek help, for ex.
That said, GN is enjoying a much more active development than panels and buttons of the UI so it’s much less stable. We keep getting new data types and new links, shapes and colors, so it might be totally not worth the hassle trying to also maintain an up-to-date theming structure to go with it in practice, even if we agreed on the principle.
Actually, while looking more into it, I am starting to realize, that this is an absolutely awesome way for me to learn and maybe make myself a build that I would enjoy using for a while(I would really enjoy consistent colors across the UI…), but I am starting to see that I should maybe revisit the idea of contributing in half a year or so.
It’s scattered across many places though, so when the time comes… maybe all that copy pasting for 23(or whatever number this ends up with) types of sockets might actually be a good idea for a newbie to do instead of wasting more experienced developer’s time. So again… I don’t know…
Color wheel occupancy is not ideal as it is, colors having been added one after the other. Since more types are coming (sound, etc) I think they need to be reshuffled. I already get confused by all the shades of red/purple. I agree with your reasoning pertaining to themes being personal, but a better default for most people would be nice, at least once we know most types are already in.
That’s completely off-topic. I was just wondering specifically if adding those colors to themes might be seen as useful.
I think that would be the right thing to do if one accepts the idea of themes in general(which is in line with Blender theme system existing). It seems there is an argument that the colors should be standard(whatever they are) and not changeable for the sake of them being recognizable. I think it’s a very valid argument, but in my view it’s an argument against themes in general, not against adding these colors to themes. …but it seems there aren’t many people who agree or care about this so maybe it’s not as important as it seems to be to me personally.
I’ve had trouble with wanting to change a color that doesn’t seem to be available in Preferences (then found it was inexplicably linked to the gizmo color, but still). It’s both my preference and in my opinion an accessibility issue that every UI color in Blender be individually changeable in the Theme setting — of course “every UI color” should include node sockets and noodles.
The feature is that its not possible, for universal understanding like you and others already pointed out.
I agree with your readability concerns, but I feel like those can be better addressed by adding patterns rather than colors. I feel like bundles and closures would be a good starting point since patterns seem to be a statement of dimensional depth (single vs field) instead of data types (colors).
It seems people really don’t want this But I did manage to do it and the experience was an absolutely awesome introduction to Blender’s source code for me, and I can enjoy a theme that is getting to be a bit more uniform. I have a thread on Blenderartists about that: https://blenderartists.org/t/decided-to-try-and-make-a-blender-ui-theme/1624413/
I imagine people have different priorities rather than being against it. I wouldn’t mind having the option, but would much rather see separate Edge Width and color settings for splines, decoupled from mesh edges for instance Maybe I should make a post on RCS. Good to see you working on it over at BA though.
But I think it’s mostly a bit mismatched thinking. I really get the idea to keep everything consistent and symbolic. The colors do communicate information and it’s important to speak the same language everywhere with them. But that is an argument against themes in general and I think that’s why the downvotes on RightClickSelect. Since themes exist in Blender, I think every single color that you see should be in them. To me them not existing for node noodles is the same as not including some terms for translation. I use Blender in English and would never consider using it translated to my native language, but then if translations exist, it would be wrong to not include some texts in them.
Pinned UVs are also not in themes as well as some colors in UV editor like face dots for some reason. There are many colors in the themes that do nothing as well. I think I could work on that in the future. I am completely new to C/C++ though, so I am not sure how useful my work could be just because of my skill level. I am interested to tinker with it for my own pleasure though.
This could be done right. The theme editor should simply get a new section under ThemeUserInterface called “Types” and each type blender supports would get its own color. These type colors would then consistently be used across all different editors, such as GN editor, shader editor, compositing editor and even property panels that also have type based color coding:
Then, any new developer developing any new feature/editor that works with types would get the colors from the ThemeUserInterface types section, and any time blender gets a new data type, it’d go there.
At the moment node editors are combined already under Node Editor:
Node sockets and noodles are related to nodes so that’s the intuitive place for the user to look for them in my opinion. Separating them would make it more confusing and inconvenient for the user when creating themes. When you are creating a theme, you sort of work on an area, and it’s convenient if everything for it is one place like node colors and node socket colors should in my opinion be in the same place.
Maybe I should make a post on RCS. Good to see you working on it over at BA though.
