Page MenuHome

For Discussion - Small Outliner Changes
ClosedPublic

Authored by Harley Acheson (harley) on Apr 5 2019, 1:03 AM.
Tokens
"Like" token, awarded by kioku."Like" token, awarded by rjg."Like" token, awarded by JulienKaspar."Like" token, awarded by pablovazquez."Like" token, awarded by billreynish."Like" token, awarded by Zoot."Love" token, awarded by jonathanl.

Details

Summary

I don't expect all, or even any, of these changes to be approved but they might spark some discussion.

The round circles behind some icons are made a bit larger so they are much less likely to overflow at the edges, as noticed with Collection, Mesh, Mesh, etc.

The open/close triangles are drawn with the crisp vector code we use elsewhere, like in Properties, rather than the fuzzier icons.

When multiple icons are shown on a collapsed row there is a little vertical separator. That was always drawn darker on all backgrounds. With this patch it uses the text color (at lower opacity), which matches better as the theme changes. And is narrower so it is a little less striking.

The hierarchy lines are removed. They never did much good. And the lines were visible *through* the icons, which looked terrible. In the capture below you can see the line inside the Collection icon. I'm sure some people loved them though.

Selected rows did not match up quite to their target rows, leaving black lines around it. This makes them fit better.

Subtle changes, except for the loss of the lines, but you can see here before (left) and after (right):

Diff Detail

Repository
rB Blender

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Ok, I understand this very well. I'd emphasize the "selected/active" and "selected" coloured text labels with bold fonts, if it's possible. And black round backdrops would be noticeable as well as coloured, but with way better local contrast.

@Andrzej Ambroz (jendrzych) Is there a place where I can download the svg versions of the current icons please? I would like to make some more proposals and don't like to retushe the icons screenshots in photoshop... :(

Another question: Is there a place, where I can drop some fundamental UI concept proposals, like how to basically organise scenes e.g. and ideas how overrides could be handled in the future etc. ?

Thank you
Chris

This patch is meant to only propose some visual changes, separate from functional changes, to avoid getting into bikeshedding weeds. I think how it looks right now makes it all seem a bit more complicated than it really is. I mostly wanted something we could use to look at and then decide what parts we might like changed or not. If keeping everything I think I'd rather hide the hierarchy line code behind a conditional rather than delete that section as this patch currently does.

@Pablo Vazquez (pablovazquez): Have you ever looked at reducing the left-side margin when in ViewLayer mode?

Strangely, the left-side margins are (sort of) consistent throughout. No matter what mode the icon of the first item is always at the same position. It looks funny in View Layer mode because we have a root (Scene Collection) that we don't allow to collapse and so there is no arrow there. And that makes sense - what would be the point of collapsing it all to a single line? But does that mean that when the root cannot be collapsed we can then move it all to the left a bit? That might be nice, although it would be a bit inconsistent as modes change. Thoughts?

The weird thing to me is the inconsistency of the parenting. If I have multiple scenes and then view as "Scenes" mode then the root nodes are my scenes - I can collapse everything to two lines: "Scene" and "Scene.001". So shouldn't "View Layer" be the same? Shouldn't each layer be root nodes, rather than just have the current layer's things inside a single Scene Collection?

@Brecht Van Lommel (brecht) : ...don't think using 3D viewport colors....I think new outliner theme colors

For sure. That would help a lot. I was just trying to use what was already available for this until we knew what we wanted.

@Brecht Van Lommel (brecht) : color for active collections...

Yes, the blue background I used for the active collection is far too subtle. Logically the active collection should be highlighted in an identical way to how the active camera is shown versus other cameras for example. Less variations of highlighting is always better.

@Andrzej Ambroz (jendrzych): with bold fonts, if it's possible

I'd love to have bold text, but we don't have that. We have a couple places where we overprint to make bold (looking at you popup hints!) but that is horrible. The best bold requires using multiple font files, but the font library we use (freeType) does support "embolden" from a single font which does look pretty good. When looking into hooking that up it starts off looking trivial then gets far beyond me when getting into the details. Best left to someone who knows what they are doing. LOL

@Christoph Werner (Taros) : The svg of those icons can be found in the first post on this thread.

This patch was updated for two reasons:

  1. So that it applies with current master as of this morning. A recent change in related code would have kept the old version from working.
  1. Highlighting of active collection (and active scene) are now done identically to the way that active camera, active material, etc are shown. The earlier proposal highlighted those with a background circle that was taken from the highlight bar (blue) but that was far too subtle. This way it is more noticable but also more consistent with other highlights.

Following illustrates the highlighting of active collection, the second of the three:

@Harley Acheson (harley) - is there a possibility to change the backdrop circle's colour via Preferences panel? I can't find it. Would like to check out other colours. Deep black first.

@Andrzej Ambroz (jendrzych): is there a possibility to change the backdrop circle's colour via Preferences panel? I can't find it. Would like to check out other colours. Deep black first.

No, I added no new preferences or theme settings. I would definitely add some if we decide we want any of these changes though. At the moment the blue bar is from TH_SELECT_HIGHLIGHT, The icon backgrounds: 3dView TH_SELECT for selected objects, 3dView TH_ACTIVE for active objects, 3dview TH_FACE_SELECT if those objects are in edit mode. If they are otherwise active in some way (active scene, active collection, active camera, etc) then the circle is just a faint white (pure white with 25% opacity)

Do you have anything specific or interesting in mind? Love to see a mockup...

The grey circle backdrop makes icon look muddy and dull. I use orange for ObData icons (instead of green) and the 25% white backdrop makes all those icons unreadable. It should/must make the item pop out, so - everything that pumps up local contrast is welcome. I'd try to make the circle backdrop black or make a proper entry in Preferences and let a user to choose colour that fits his theme.
Anyway, I'm not fan of the circle highlight - it makes things busy and is not elegant design-wise in its curent incarnation.

@Harley Acheson (harley) - some sketches for You (with improoved Camera ObData icon):

From the left:
1 - current implementation;
2 - Your tweaked version (slightly bigger circle backdrop) - mind poor local contrast. The circle is still too tihgt and interferes with icon's shape.
3 - my proposal {a} - dark backdrop, with better local contrast, but the circle is still too tihgt and interferes with icon's shape.
4 - my proposal {b} - generally the same as above, but the backdop has one pixel bigger radius, which makes the circle more visible and separated from the icon's silhouette
5 - my preffered solution {c} the backdrop gets icon's colour and the pictogram iteslf becomes black or takes colour of the background. Wthis mod and the bigger backdrop it's easy to spot the edited ObData and the pictogram doesn't suffer from lack of contrast.

A mockup:

@Andrzej Ambroz (jendrzych) : The grey circle backdrop makes icon look muddy and dull

Yes it does and all of your sample look nicer. However...

But what screws us up is that the method we are using to get colored icons in Outliner does not allow us to change their colors dynamically in there.

We are currently taking the icons that are used in outliner and making them all all have a set color. Works in a simple case. But it does mean that any usage of those icons are going to be exactly that color. Even when used outside of outliner. So we have troubles when showing the list of modifiers in the properties editor when using a light theme. In that case we'd like dark icons on the light field in Outliner, but light icons used in the dark menu of modifier items.

I've tried mentioning this flaw before but without purchase.

How it should is those icons would just be logically grouped and then colored at the last moment when they are drawn. The shader we use can make any of your white icons be any color at all. But we don't allow this ability at a higher level. What we need to do is add a color member to uiBut and use that color if set, or TH_TEXT if not. So anytime we deal with a uiBut we can draw the icon any color at will. And then also add members to operators that set that uiBut member as well. That way we define the "autokey" operator and also set the color to TH_RED or whatever.

In a nutshell we can't at the moment do as you'd like. And if drawing a black circle when using the default dark theme it does not give any highlight at all.

This update removes the unnecessary space to the left of the tree when in View Layer mode

@Pablo Vazquez (pablovazquez) - Have you ever looked at reducing the left-side margin when in ViewLayer mode?

Your suggestion looks great that way. The change in alignment as you change view mode is not really a noticeable thing. It seems to look nice and make sense regardless.

The following image shows how it looks with this version. Two cubes, one selected and is being edited. Two cameras, the first active. The first collection is active.

I had actually hoped we could make use of this gutter on the left for selection purposes.

The idea was that you would be able to click and drag from the gutter to start a box selection:

@Harley Acheson (harley) - limits and tradeoffs then...
My vote goes to tad bigger backdrops. 1pix longer radius, than in Your patch. A 25~50% lighter outline would improove the backdrop's appereance.
Yours on the left, mine on the right:

Mockup:

@William Reynish (billreynish): I had actually hoped we could make use of this gutter on the left for selection purposes.

That is possible. But it is best to consider what you are actually going to select and also think about other outliner modes besides View Layer. In your example your selection includes the root "Scene Collection" and not sure if that is a thing to select along with other things in a single selection. And if you want to have a selection that includes the root like that then you might be asking for MORE gutter for the other modes. So I'm just saying please examine ALL modes and think about what we want to drag-select and we can find something that works all around.

@Andrzej Ambroz (jendrzych): bigger backdrops. 1pix longer radius, than in Your patch.

I didn't think about using a background circle size that overflow the row size. Although it doesn't look too bad in your mockup, try it again when those circles overlap each other like when two highlighted items are in following rows.

@Andrzej Ambroz (jendrzych): A 25~50% lighter outline would improove the backdrop's appereance.

I do like those outlines but again, they only really work well when the circle is enlarged, so there is some padding between the icon image and the outer edge of the circle. And when they get larger those outer outlines will also overlap. So I'm just asking you do another mockup that is for less ideal situations.

This version:

  • Doesn't push the Layer View over to the left as far. Trying to leave enough space for drag selection but still look nice and match the space available in other modes.
  • Fixed a dumb error where the "active circle" would be in the wrong place (only) for the root "Scene Collection".
  • Increasing the brightness of icons when shown on a collapsed row. The current behavior, and my earlier patches, showed those collapsed row icons at lower opacity than when they are show when expanded out. But it isn't all or nothing. You normally would see some out and others in so having the opacities the same might make more sense. They certainly look less "muddy" this way.

@Harley Acheson (harley) - will make a sketch but have to ask You to provide me a screenie depicting situation, You're interested to see. This will help me to prepare proper mock-up. Thx in advance.

@Andrzej Ambroz (jendrzych) : have to ask You to provide me a screenie depicting situation

No problem! I mean like the following where those circles would overlap if they are any bigger (the two cubes being edited)

Note that in the above screen capture, the icons on the collapsed rows are a bit smaller than normal. Just an experiment to ignore. Everything else, including those circles, are the same size as seen when using the patch.

Another small change:

Here the highlight background "circles" are more rectangular. The icons are designed to fit inside a square, so the circles were very likely to cut off part of the icons at the corners. Or the very least make them look like they are sitting too high or low, depending on how they are made.

The more rectangular the better they match the icon proportions. And they look more like a part of the icon. I think this looks quite nice...

Looking good I think. I think it's good to do.

Looking at it here with @Pablo Vazquez (pablovazquez) who suggests to remove the separation lines between restriction columns too:

Adds an extra cleanup on top of your other changes.

@Harley Acheson (harley)
A promised mockup with big circle backdrops (a version without outline in dashed box):

And sqare ones with a twist - tad bigger (using full line height = more padding around the icon and more backdrop separation from the pictogram), with less rounded corners (the same radius as for buttons) and with a slightly less transparent outline (a version without outline in dashed box):

Finally, a variation which uses icon's colour for the backdrop. Less obtrusive an not so colour-messy, yet still efficient. Clean, elegant - pure winner IMHO:

@Andrzej Ambroz (jendrzych)
I really like the third mockup! As another thing to point out: There is currently also the issue with making the selected objects clearly visible when they are within collapsed collections.

Let's say the object contents are disabled in the filtering options and the collections have some of the visible objects linked. I like how with this visualisation it's much clearer where the selected objects are instead of using the smaller white circle that is currently used.

@Julien Kaspar (JulienKaspar) - I imagine, that - for consistency sake - the text label of Collection containting selected-active object, should be bright orange coloured. Collection containing just selected objects = dark orange coloured text label. Backdrop under the icon in this very case will be a bit confusing. I prey for bold fonts here though - is it really so hard to be made?

With this change:

  • The black vertical bars between the restriction icons is removed.
  • The highlighted icons have a border. Trying to make them a bit more noticeable but not too noticeable. LOL

The following is a good illustration of how it looks:

The second of the two collections is active. The second collection contains the active camera. A Text object is selected in the viewport and is currently being edited.

Loving how it looks! For me this is ready to go, such an improvement!

Thanks for taking the time to work on it.

With this change:

  • The black vertical bars between the restriction icons is removed.
  • The highlighted icons have a border. Trying to make them a bit more noticeable but not too noticeable. LOL

The following is a good illustration of how it looks:


The second of the two collections is active. The second collection contains the active camera. A Text object is selected in the viewport and is currently being edited.

I like it too, but not sure about the outline. Filigree outlines are always "critical". What about the blue bar? Is it the current "mouse over" in this state?

@Harley Acheson (harley) - please, try to use icon's colour for the backdrop and its border, like I proposed above. I can't see a reason for: (a) using orange colour for underlining the fact, that the ObData is actually edited; (b) using different colour for active Camera ObData, which is actually editable at a time. Reducing number of used colours will make the Outliner look cleaner and organised yet let it be communicative enough. Right now we get a kind of christmass tree.

@Christoph Werner (Taros) : not sure about the outline. Filigree outlines are always "critical"

To your eye do you imagine that those outlines should be removed or just made less stark? To my own I would leave the one around the "being edited" icon as it is (or even stronger), but make the other "active" ones a bit dimmer.

@Christoph Werner (Taros) : What about the blue bar? Is it the current "mouse over" in this state?

The blue bar is unchanged from the current behavior, so indicating that the row is selected in the Outliner. The hover is also untouched, so is becomes a bit lightened on mouse over. I purposely did not include that in the capture because it can look confusing since you don't also see the mouse cursor there to explain it.

@Andrzej Ambroz (jendrzych) :

Please don't read the following as authoritative, but more as suggestions or questions. In matters like this my own opinion is much less informed than others here, including yours.

I don't understand the combination of wanting to use the icon color for background, while also saying that doing so will reduce the number of colors. Would that not necessarily increase the number of colors used? So I am missing something there.

Right now I am only attempting to highlight two things: items that are "active", like one active collection among many, or the one active camera. And the second being that an item is currently being edited. So only the two different things.

With just two states to indicate is makes sense for "active" to be fairly generic and Editing to be more important. The orange you see is NOT meant to be indicative of the orange used in the Outliner but to be taken from "Selected Face" while editing a mesh. Later that, and others, would be theme settings I imagine.

My biggest worry about using the icon color for background is that it would not only increase the number of colours used, but also eliminate the chance of indicating the edited state, and also add new inferred meaning. Right now we do have some red and green icons, like for a camera or light. But if those get much more green and much more red from their backgrounds it will look like red and green have meaning when they do not.

The other issue is that the current way we are dealing with icon colors (complained about earlier) means that I don't have the icon color at that point.

@Harley Acheson (harley) - take a second look at my proposal:

Using colour of an icon for its backdrop will cerainly reduce using of colours, just because now we have green pictogram against orangey/ellowish backdrop (two colours within small chunk of space). Lets add a material to the stack and we get reddish icon against orange/yellowish backdrop... Three colours. With my proposal we'll get less colours - green ObData against dimmed / transparent green backdrop plus reddish Material ObData against dreddish backdrop. Two colours in clean and readable configuration. The backdrop will work as the icons colour and shape amplifier.
No need for differentiating ObData under edition from active Camera or a Material, just because all of those items do not have other states. Active Camera is actually an ObData, that is under edition. Isn't it? The same applies to the Material ObData. The backdrop itself is enough, no need for colour differentiation IMHO.

@ jendrzych:

Sorry, I think you would have to dumb it down further for me because I am still not getting it. When I look at that third mockup of yours I only see more colors.

So in this example there is nothing too special, except that there are two lights, and one is active (so would be shown in Properties). And there are two cameras and one is active.

They way they are highlighted in this patch makes their hightlight seem fairly similar. Would yours not give a red background to the light and a green background to the camera? Wouldn't users wonder why the light looks to be in alarm while the camera would seem to be okay in some way?

Ha! You've changed it. I referred to screenies with yellow backdrops under ObData under edition. Now all backdrops are 25% white, and that's ok, but mind that using icon's colour will not affect the icon's appereance, while 25% white makes it somehow washed out. I may stare at them too long though :P

@Andrzej Ambroz (jendrzych) : Ha! You've changed it...

Maybe?

If you look at the very last image I sent, showing the light and camera both highlighted. If you were to then select (in the 3D Viewport) the Text object then the name "Text" would turn orange to indicate that it is selected. Go into Edit mode and then the green "curve" icon beside it would get that orange background you saw on earlier captures to indicate it is being actively edited

@Andrzej Ambroz (jendrzych) : while 25% white makes it somehow washed out. I may stare at them too long though :P

Feel free to chime in here with even tiny details. Personally I think the regular active highlight can be a little less strong because of the added border. It seems just a bit too important at the moment. While "In Editing" should remain strong.

As far as I get it, the orange backdrop is still there, but ain't present at Yours mockup? Still do not catch the need for differentiating Curve/Mesh that's being actively edited from the Light, for instance. Does orange backdrop mean "this item is in Edit Mode"? If so, why is it so important to show such info in Outliner? Is it possible to enter the Edit Mode from Outliner? It's not, as far as I know.
Anyway, if the "Edit Mode" state of an ObData in Outliner is a must, I'd look for the way to show it without using a colour change of the backdrop. At least would avoid using a colour that's different from the icon's hue. My proposal od using ObData colour may still be valid, but shoud be limited to the "Edit Mode" state. Have to sleep on it.

@Andrzej Ambroz (jendrzych): does orange backdrop mean "this item is in Edit Mode"?

Yes, exactly.

@Andrzej Ambroz (jendrzych): If so, why is it so important to show such info in Outliner?

It might not be. It is very possible that I gave it more importance to that than needed or wanted. I have no idea. I haven't had any specific feedback on that. It is all up for discussion, but *feels* right to me as I use it. Especially when there are nearby highlighted icons, for example when a material that is active is on the same row.

@Andrzej Ambroz (jendrzych): Is it possible to enter the Edit Mode from Outliner? It's not, as far as I know.

It is though! If that item is expanded then you can click on the mesh icon (for example) and it will go in and out of edit mode. If you have multiple editable objects you can click on one or the other to edit each one, or even shift-click to put both into edit mode. Not sure how useful that is, but not for me to judge at all. LOL

Harley Acheson (harley) updated this revision to Diff 14716.EditedApr 12 2019, 10:14 PM

Minimal changes:

The icon background area was just a bit high so highlighting rows could interfere at the edges. Looks nicer.

Some small opacity changes to the icon backgrounds to make regular active look a bit less strong and alarming, and to make them interfere less with the icons.

@Christoph Werner (Taros) : not sure about the outline. Filigree outlines are always "critical"

To your eye do you imagine that those outlines should be removed or just made less stark? To my own I would leave the one around the "being edited" icon as it is (or even stronger), but make the other "active" ones a bit dimmer.

@Christoph Werner (Taros) : What about the blue bar? Is it the current "mouse over" in this state?

The blue bar is unchanged from the current behavior, so indicating that the row is selected in the Outliner. The hover is also untouched, so is becomes a bit lightened on mouse over. I purposely did not include that in the capture because it can look confusing since you don't also see the mouse cursor there to explain it.

The outlines should be removed, because of too much information. Additionally they are disturbing the main color and start to "blur" small icons (in most situations). In this case: "less is more". So I agree with @Harley Acheson (harley) .

About the blue line: So it works concurrently? Selecting an object in the viewport will activate a blue bar in the outliner of the selected object(s)?
As long as this is not guaranteed I don't see a reason for an independent selection state in the outliner. Correct me please if I miss something in the outliner funtionality to use viewport independent selection states.
The user would not understand it because the outliner basically represents the "text version" of my whole project. So when I select something in the outliner it should be selected in the viewport if possible and reverse (There is always some data information that can't be represented in the viewport).

... Does orange backdrop mean "this item is in Edit Mode"? If so, why is it so important to show such info in Outliner? Is it possible to enter the Edit Mode from Outliner? It's not, as far as I know.
Anyway, if the "Edit Mode" state of an ObData in Outliner is a must, I'd look for the way to show it without using a colour change of the backdrop. At least would avoid using a colour that's different from the icon's hue. My proposal od using ObData colour may still be valid, but shoud be limited to the "Edit Mode" state. Have to sleep on it.

To answer your question: Yes, you can activate the edit mode of an object in the outliner. It's an old feature and possible in 2.7x versions, too.

In my opinion basically the ouliner selection colors should be always familiar with the viewport colors if possible.

Brecht Van Lommel (brecht) requested changes to this revision.Apr 23 2019, 5:25 PM

I really like the look of this. Still missing new outliner theme colors before we can commit this.

This revision now requires changes to proceed.Apr 23 2019, 5:25 PM

@Brecht Van Lommel (brecht): I really like the look of this...

Actually didn't expect that, but thanks!

Was throwing lots of ideas in here and hoping to get some feedback on what works and does not.

For one thing I don't think we can actually remove the relationship lines, as a dotted variation will probably be used for children not in that collection. @Dalai Felinto (dfelinto) is still doing active work in there to do with parent/children.

@Brecht Van Lommel (brecht): Still missing new outliner theme colors before we can commit this.

I will go on the assumption that we like most of the other things in general and will move a bit forward then.

Changes:

Applies to current master

Relationship lines are not removed, only commented out (for now). Dotted relationship lines remain for children that are not in parent's collections. Lines are scaled with Line Width preference.

Current state:

The following shows two collections, the first is active. Two cameras (main is active). Parent and Child relationship with Child in other collection. Parent is selected and is being edited.

@Harley Acheson (harley) - not using the yellowish backdrop's colour for its outline, makes the backdrop look a kind of messy.

@Andrzej Ambroz (jendrzych): not using the yellowish backdrop's colour for its outline, makes the backdrop look a kind of messy.

The icon outlines are just a very low-opacity white over the background color so it just brightens what's there. But I will be making theme colors for these things shortly so we can use a better color for it. Combined with being able to change the icon category colors too should make it look okay in the end.

This seems good to me with the latests updates. @Brecht Van Lommel (brecht) @Pablo Vazquez (pablovazquez) can you take a look too?

Brecht Van Lommel (brecht) requested changes to this revision.Apr 25 2019, 1:38 PM

Lack of outliner specific theme colors is still holding this back for me. Also would be good to ensure Blender Light still looks ok with this, and if not adjust it.

This revision now requires changes to proceed.Apr 25 2019, 1:38 PM

I really had only intended this as a way to gather feedback from the separate changes here. To help gauge what people thought of each change.

I really don't like making complex changes to a lot of unrelated things. So unless anyone complains I am going to break off a few smaller atomic changes into separate little patches that can be approved or rejected separately.

This will leave this one with (mostly) just the changes to how selected and active are shown in the names and how icons look. Then will add a few themecolors and try to get this part through.

Gavin Scott (Zoot) added a comment.EditedApr 26 2019, 11:36 PM

Another small Outliner thing along similar lines would be that I don't think there's any indication currently if a Collection is set to Holdout or Indirect Only for the current View Layer. Would it be easy to add some icons after the collection name to indicate these states?

Exclude is currently indicated by disabling the Collection (dim name and unselectable and unexpandable). This is actually somewhat annoying as I think you might want to interact with stuff in the collection even though it's excluded in the current view layer, so maybe just have an icon for this state like the other two above instead?

Edit: probably covered in https://developer.blender.org/T61578

Have cleaved off a few minor things from here into separate patches to simplify this a bit: Remove Outliner Highlight Selection Gap. Outliner Hierarchy Line Width. Remove Outliner Vertical Separators

This leaves this patch just about changing the way that selected, active, and edited objects are shown. And now you are able to specify these three colors in theme preferences.

With this patch applied you'd have to go to theme preferences and set some colors you like:

And then you will see those colors in the Outliner. The following shows a scene with two cubes, both selected (one active naturally), indicated by the Orange names. And both are being edited, indicated by the color under the mesh icons.

I'm not sure why you split this into many patches - now we'll have to approve and commit each one separately.

Anyway, the issue was that it was using the theme colors from the 3D View. If you can make it so it uses Outliner-specific theme colors which are already set up in the theme correctly, then I think we can approve and commit this.

@William Reynish (billreynish) : I'm not sure why you split this into many patches...

I've had problems in the past with patches that touched different issues simultaneously. People might like one thing and not another so this gives you a chance to say yes/no to atomic changes. Otherwise you can have something that people generally like but then got bogged in weeds of bikeshedding where we argue about the specific color of one dumb thing.

Smaller atomic changes are also easier to maintain and apply since they make less changes. Other people can commit changes that are less likely to affect each one. Smaller atomic changes are also easier to revert, since it affects only one small thing not other other unrelated things.

Anyway, the issue was that it was using the theme colors from the 3D View. If you can make it so it uses Outliner-specific theme colors...

Yes, this patch adds Outliner-specific theme colors for the three colors I introduced, so does not use anything from the 3DView colors.

...which are already set up in the theme correctly

Although this works as expected, the new theme colors I added will be initially seen as black when you apply this patch. I am assuming that the colors would be set in the default blend.

I did add defaults for these colors in userdef_default_theme.c but they still initially come out black until saved the first time. If there is a better way of doing this then I will need a pointer from someone smarter, like @Brecht Van Lommel (brecht) or @Campbell Barton (campbellbarton).

Ah ok, sounds reasonable then. Perhaps @Brecht Van Lommel (brecht) has an idea of what to do for the updated theme entries.

@Harley Acheson (harley) What is the status of this, now that you split this in several patches? There seem to be more nice changes here we could adopt.

@Harley Acheson (harley) What is the status of this, now that you split this in several patches? There seem to be more nice changes here we could adopt.

The little parts that were split off have all committed.

This one one does the bigger things and still applies to master but requires review by @Brecht Van Lommel (brecht). This is using theme settings for colours but they start initially black. Not sure if I missed something or if that is just set in the default blend.

The theme colors in existing preferences need to be initialized from the defaults. See do_versions_theme(), there's a bunch of similar cases there. release/scripts/presets/interface_theme/blender_light.xml needs to be updated as well with appropriate colors for a light theme.

After re-testing this, I noticed one issue:

It's not possible to click the ObData icons to enter Edit mode. Did this get accidentally removed? I'm pretty sure this used to work?

It only works when expanded:

Then you can click those icons to edit.

If you are able to do that, plus the do_versions thing to make the theme work, I think we should be able to get this in.

@William Reynish (billreynish) : It's not possible to click the ObData icons to enter Edit mode. Did this get accidentally removed? I'm pretty sure this used to work?

Yes, that is the current behavior that remains unchanged with this patch.

We did talk about it though, as that would be a really nice change. But I could not figure out how to do that, but hopefully I (or more likely someone else) will figure that out later.

The current code is doing deliberate things to not have those work as buttons when not expanded. And yes, I did notice that tselem_draw_icon()'s last param is "is_clickable", but forcing it true does not allow any of those items to work as buttons when collapsed. There is some other (so far unknown to me) mechanism keeping it from working.

Thanks for @Brecht Van Lommel (brecht) this patch now uses do_versions_theme() to help show initial default theme colors. And also has a alternative settings in blender_light.xml.

Tested. Seems to work now with the theme. These changes seem good to me.

@Brecht Van Lommel (brecht): should we get this one through as well? I think your earlier objection was resolved.

Yes, it's on my list to review.

Brecht Van Lommel (brecht) updated this revision to Diff 15349.

Update for latest master.

Brecht Van Lommel (brecht) requested changes to this revision.May 15 2019, 2:37 PM

In Blender Light, it's very hard to see which is the active collection. In general the active backdrop for icons is not visible enough in Blender Light.

Other than that I found no issues.

This revision now requires changes to proceed.May 15 2019, 2:37 PM

In Blender Light, it's very hard to see which is the active collection. In general the active backdrop for icons is not visible enough in Blender Light.

I can add this to the list of fixes to the themes I'm doing today, so this patch can make it.

I also don’t really like how the Light theme looks in Outliner after this patch, but am not sure if it actually looks worse or just different. So hard to use variations of text colour on light backgrounds.

The color for this is hardcoded, I'll commit it with some tweak to keep it visible in both themes.

This revision is now accepted and ready to land.May 16 2019, 2:38 PM
This revision was automatically updated to reflect the committed changes.