Using RNA at the level of building a tree can work (of course - the data display uses it).

But am a bit wary of this --- is it really helping to display granular links?

Armature/Curve/Lattice for example are a kind of implied parenting (objects owning other objects) - even if the relationship isnt a parent, strictly speaking.

Im just not sure if we really help users much here... if you want to inspect modifiers you better look in the modifiers UI...

Once this is added should we do the same for constraints, drivers ... etc? ... where does it end?

And if you want all possible properties - we have a data browser (admittedly not all that usable since its incredibly granular). But thats the point, why is being granular helping here?

I just dont see where this fits. What task this makes easier.

If there is some need for a graph of the scene, (like 2.4x OOPS), maybe we should have some different tool to the outliner.

Note, that outliner already has serious performance problems on large scenes, so am not really keep to add more complexity unless its optional... or there is some good use-case that makes it necessary.

Its problematic since we dont have a clear definition of what should/shouldn't be in the outliner.

However for now I think the rule of thumb should be to help with scene-management. (in the default view at least) relationships between objects, parent, child... high level view

Would be good to get feeback from experienced users, maybe I overlook some issue.

I see the performance problem... And I see where you are heading in the design of the outliner (keeping it a very high-level view)
I was used to using an outliner as an editor as well (in other programs), so as long as I can filter out unneccessary information ("Show foo", "Show bar" -- which we also talked about) to keep my focus I could very quickly edit relations in there, which i still think would be a plus... I dont have to select anything to bring up properties, I can do quickly for different objects etc...

reg. functionality:
This is existing functionality [just very inconsistent... why display this for some modifiers, but not others?]
If I implement the missing modifiers (using the hardcoded style as is now) it'll be bad to maintain (and certainly people will forget about the outliner if they write a new modifier...)

So, how to proceed?

1. fill the gaps (hardcoded style? or foreachIDLink? as you also suggested)
2. remove the whole display of "low-level-objects-in-modifiers-relation"
3. leave the mess as is ;)

@Philipp Oeser (lichtwerk) - RNA level constraint / modifier level links could work... if they only generate when the modifier is expanded.

IIRC the way outliner works now it generates the tree even when elements are collapsed.

Then at least its not being a problem and users want to see them can do so,

However this may be a bigger change then it sounds. I didnt touch this code in a while but changing logic for how the outliner tree is managed may not be trivial, needs some investigation.

To summerize:

While this change isnt bad code it runs in a performance critical area.

It should either.

• Lazy initialize the modifiers. (so it doesnt show on tree build)
• Show modifiers optionally and disable it by default (even then, users may leave on by accident and get real slowdown).

So for now Im rejecting this patch. while the functionality is OK, its not something we can accept with the current outliner design.

fair enough, lets see if I can come up with a good enough solution (either display filtering or lazy init) -- if at all... :)