I’m currently loving the way it’s looking. Great job.
There’s one thing that’s been bothering me for ages though.
The extreme padding on the left of the whole outliner. I always have to keep adjusting it to show more of the written info when I scroll. If you compare to how close the right icons are to the border, I think it could shrink by a LOT. This is specially important on smaller screens.
If you have a layout scene with thousands of objects and complex relationships ideally you want to select something in your scene and see it right away in the outliner.
I can’t stress enough how important this feature would be to me. I use a lot of Collections in my scenes to help me stay organized and the amount of time I spend trying to figure out what collection an object is in is embarassing. Having a blatantly obvious highlight would be amazing.
I’ve said it other places but I’ll say it again - this is all amazing work you’ve done and I am so excited for this to go into main. Thanks for your hard work Nate!
I agree. We used to have this pre-2.8, with the dot on the layer button turning orange.
@dan2 @Dheim @Zsolt_St I’ve started on the parent highlight. It’s a “dumb” solution, but it works very well and took about 1 minute 
It works surprisingly well, but I already found one issue that I think should be resolved.
Try it here: https://blender.community/c/graphicall/Qmbbbc/
The issue deals with the selection syncing algorithm. When you select an object in the viewport the outliner scans over all the objects and then flags the outliner element as active if the object/bone is active. But when you select in the outliner, a different type of element can be come active. For example, if I were to select a collection in the outliner, it would be the new active element.
The parent highlight is based on the outliner active flagged element, not the true active object or bone. I think this may be okay, but it is also possible to make this only show the active object/bone, not for other outliner selected data.
The build with the feature is already live. It only works for objects and bones which I think is just fine. It reuses the mover highlight theme color, but I think a separate color would be best. Any suggestions?
Any particular reason why?
Every software i know that has some kind of hierarchy management - starting from a basic file manager(deleting parent dir removes children) through all kind of graphical applications like fusion360, inkscape, illustrator, photoshop etc. - behave the same, when deleting parent object children are deleted also.
It’s over a decade since i last used max, cinema4d and don’t really remember how it works over there, but somehow doubt it’s any different
The only reason i know why it’s made that way in blender is to not delete accidentally objects, but that is not really a good solution it just adds extra confusion… a simple warning would be a lot better imho.
Luckily that is easy to fix(at least in the outliner, not sure yet about the 3d view) on my side by simply changing the shortcut.
Is there any way to fix the drag and drop “issue” on my side?
I don’t care about the defaults as long as i can change it my self.
This is great! I’d personally go with a more muted/desaturated version of my blue highlight color, but if it’s exposed in the theme settings everyone could decide for themselves.
The new build seems to require a factory reset from command line (something I didn’t notice with the previous ones) else it crashes instantly -
Read prefs: C:\Users\DD\AppData\Roaming\Blender Foundation\Blender\2.91\config\userpref.blend
found bundled python: C:-=Utils=–=Blender=–=GSOC2020=-\Outliner\blender-2.91.0-git.37f9b915acef-windows64\2.91\python
Exception in module register(): C:\Users\DD\AppData\Roaming\Blender Foundation\Blender\2.91\scripts\addons\BoxCutter_init_.py
Traceback (most recent call last):
File “C:-=Utils=–=Blender=–=GSOC2020=-\Outliner\blender-2.91.0-git.37f9b915acef-windows64\2.91\scripts\modules\addon_utils.py”, line 382, in enable
mod.register()
File “C:\Users\DD\AppData\Roaming\Blender Foundation\Blender\2.91\scripts\addons\BoxCutter_init_.py”, line 36, in register
operator.register()
File “C:\Users\DD\AppData\Roaming\Blender Foundation\Blender\2.91\scripts\addons\BoxCutter\addon\operator_init_.py”, line 36, in register
shape.register()
File “C:\Users\DD\AppData\Roaming\Blender Foundation\Blender\2.91\scripts\addons\BoxCutter\addon\operator\shape_init_.py”, line 14, in register
register_class(cls)
ValueError: validating class:: ‘USE_EVAL_DATA’ not found in (‘REGISTER’, ‘UNDO’, ‘UNDO_GROUPED’, ‘BLOCKING’, ‘MACRO’, ‘GRAB_CURSOR’, ‘GRAB_CURSOR_X’, ‘GRAB_CURSOR_Y’, ‘PRESET’, ‘INTERNAL’)
register
[DEBUG] (2020/08/21 07:34:29) mesh-fairing-master.linalg.init():L164 - Using NumPySolver
register_class(…):
Warning: ‘gwald.add’ doesn’t contain ‘MT’ with prefix & suffix
Registered Hair Tool
register_class(…):
Warning: ‘SoftMod_PT_Panel’ doesn’t have upper case alpha-numeric prefix
Error : EXCEPTION_ACCESS_VIOLATION
Address : 0x00007FF6DD54A335
Module : blender.exe
Thread : 00004dcc
Writing: C:\Users\DD\AppData\Local\Temp\blender.crash.txt
I know I got some addons, but figured it’s better to flag it since I didn’t have this issue with the last build.
And another thing I noticed, selection seems to be fiddly, something is off -
Seems I can only click select objects within the same collection, and with multiple objects selected clicking the active objects toggles it’s active state (active selection jumping from object to object)
As far as I know, the only software that makes a distinction for the active object within the outliner is Blender. Other softwares do have “active objects” per-say, they just only show it in the viewport, and they do it in the same manner as blender (with different selection colors). This means that when it comes to highlighting they only use 2 colors, one for selected objects, and another for showing that something is within a hierarchy.
I think this approach is appropriate, it’s just that would make blender have 3 selection colors. Active, Selected and “within hierarchy”. I think this may work, but we need to be careful about it. This may also come up later in discussion about parent child relationships, if they need yet another type of color which would make it 4, which truly may be too much.
Regardless here is some food for thought:
I think the current active and selected objects color doesn’t have enough contrast. If we are adding a 3rd color we need to be careful with our choices. (please zoom into this image)
In 3 and 4 I have simply taken the value from the existing active object color and bumped it up. I think this makes it much clearer at a glance, which is why I made these all in the same picture, I hope it reads well.
I think doing something like this is absolutely needed if a 3rd color is to be introduced for “within hierarchy”. For me, taking the selected object color, then bringing the saturation down and reducing the value to darken it a bit works well:
Here is all 3 colors in the same picture:
3 colors might be a lot, but I think it works well enough. And I LOVE the new white box around the active object and active collection.
Yeah, I mean filter/display settings because everytime you need to open or close collections when you change a workspace 
I think it should delete the children, and that the special operator should be “Delete Only Parent” or “Delete Only Collection” instead.
The design and organization of the outliner suggests that deleting a parent will delete the children as well.
I think most people intuitively understand hierarchies as “containers” in a sense, or structures where children necessarily follow parents.
Collections themselves are graphically represented by a box container, and in the outliner, child objects appear to be within parent objects, again suggesting a “container”.
If you were to put a bunch of stuff into a box, then throw the box into the trash, the contents of the box would obviously follow and be in the trash as well.
Not only does Blender’s own design suggest this, but also most other software (everything that I’ve used anyway) works this way, so I think the most natural and expected behavior for deleting a parent is to delete the children as well, unless a special “delete only parent” operation is performed.
On top of this, it would also be more consistent with transforming parents. If you move a parent object in the 3D view, all child objects will move as well, unless you tick “Affect Only Parents” in the transform options.
Yes, pretty much. If I delete an armature it’s not only deleting the root bone. Delete hierarchy would be used way more commonly than just deleting the parent.
Also (I know it’s not an outliner thing, just in case someone else in charge reads this), I said it a million times and I’ll say it again, pretty please let us interact with/delete hidden objects 
. This is not photoshop, unhiding a 100M poly object just to delete it is not very practical.
That being said, I didn’t hope for the child hierarchy thing to be tackled the last minute, super happy it seems to become reality!
I agree that the best option is to have ‘Delete Only Parent’ and ‘Delete Only Collection’ as the special operators in the context menu, with deleting all the collection contents and all children as the normal delete behavior. I would hope that this gets changed if it has not been already in the last couple hours.
A while ago I dug a little bit and changed few lines in the Python side to “fix” this.
But I got no answer 
@justastatue has a really good point. I couldn’t say it better.
I almost always want to delete the entire underlaying hierarchy by pressing delete button, when only the parent is selected.
The way the “Delete” currently behaves in LTS build is unintuitive and probably should be a special operation - “Delete only parent”.
This! Unhiding high-poly objects only to delete them is a struggle right now.
Thank you for your hard work, @natecraddock !
I like these mockups, I’ll look into that as an option. Also, the “active” color is not technically needed but it is used in other applications. I’ve seen it in VSCode and in file browsers.
I’m still convinced that deleting the whole hierarchy is not a good idea. This isn’t the thread for continued discussion though. I’ll give my reasoning, but further discussion should be moved elsewhere.
A few of you have compared the outliner/collections to a folder and files hierarchy. While they are similar, remember that objects aren’t stored inside collections, they are merely linked inside a collection. So an object can be stored inside multiple collections.
In this case, if deleting the parent Collection were to delete the contents, the outliner would be left with no objects. I think that is bad behavior. Again, if anyone wants to continue this discussion, let’s take it elsewhere since it’s not specific to the GSoC.
You can delete hidden objects in the outliner with the context menu or the X key in 2.90.
And the parent highlight is last minute. I’ve stopped development of new features for now, and I’m only working on bug fixing and code review. Next week is the final evaluation, so this parent highlight probably will not be included in gsoc, but I think it can still be a part of 2.91.
I always forget that, mainly because most of the time after selecting something I immediately move my cursor back to the viewport. This being context sensitive is driving me crazy
Fingers crossed for the parent highlight, that’d be a huge improvement.
Yes, others have voiced that in this thread and in the past, and I might agree. In other 3D packages, as I mentioned they, don’t bother with this in the outliner, only in the viewport. As far as I know, they only purpose to distinguish the active object in the outliner is for consistencies sake? I.e, if it is active in the viewport, it is active in the outliner. While technically not bad, I am not sure if it really serves a purpose. Is there anything that you can do in the outliner having the active object highlighted?
Some things are nice with it, it makes it really easy to see what is being parented to what from the viewport selections being reflected in the outliner. Also it’s easy to understand what is having a constraint placed on what with Ctrl+Shift+C reflected in the outliner
But the thing about these is that they are still performed in the viewport. Of course, you can parent by dragging and dropping in the outliner, but that has no relation to selections highlights, you just drag and drop things on top of what you want. What I mean is there is no function like a context menu option such as “parent selected to active”, making use of the selection highlight options.
The thing is I’m not sure if there is some features directly making use of the difference between “selected objects” and “active object”. Like, would blender explode if we removed active selection highlight from the outliner? I’m not entirely sure, it seems like no. We already have the nice rounded box around the active object, as well as it’s title turns a bright orange/yellow. If there is no real need for it, it might just be adding extra noise what with my mock-up from above.
If it is needed though, another path could be specifically adding functions to make use of it. It might be nice to have a context menu option like “parent selected to active”. In production scenes it can be difficult to parent things sometimes by dragging/dropping in the outliner if the parent is “far away”, so you usually highlight the children in the outliner, then find the parent in the viewport then parent like that. Might be nice to help with scenarios like that, where instead of selecting your children then scrolling for an eternity and stopping on the right spot (hopefully, as it goes fast), you could select the children then freely scroll to the area with the parent, the use the context menu to execute it.
As well it might be nice for allowing to bring up a similar constraint menu what with Ctrl+Shift+C in the outliner for rigging/animation. Though that might be hard to design, that way you can do more work within the outliner.
I would be super interested in knowing what blender thinks about this the whole “active selection” thing? Do we need it? Have you talked about this with your mentor?
I’m sort of OK either way, without it I think the outliner might be more concise at a glance, but if we kept it we could make use of it in the future by adding features to make use of it. Just some food for thought I suppose.
Also is this intended behavior?
Is this how it is supposed to be, or am I JUST realizing that there is a decoupling between “active object” and “active selection”.
There are a few actions that require an “active” element in the outliner. For example, a range (shift+click) selection. There needs to be a starting/active element when selecting a range so we use the active element. But you are right in that showing the active as a different color is not strictly required.
Active selection is needed for Blender overall, but we could perhaps remove the active highlight.
You just found a bug! I’ll get that fixed Thank you. This was introduced as part of fixing the context menu.
This might make sense as long as we are only talking about collections, which are containers.
But any type of object can be a parent to any other type of object, for various reasons, not just as a container. I definitely do not want Blender to delete an object that is unbeknownst to me parented to the object I am deleting.
People coming from Maya (like me) usually expect this behaviour, but I’ve come to prefer the alternative. I want to operate on selection and selection alone -if my operation does something on top of what is described, I think it falls into the realm of side-effects. The delete operator could have a “delete children” argument, called with ctrl+X for instance. That would be nice.
