Right now this is exposed in the outliner, though all this
(visible/selectable/enable) should be moved to a new panel soon.
This should really be an operator and RNA API function, since RNA is meant to be thin wrapper and this is doing recursive edits.
@Campbell Barton (campbellbarton) I need your help here.
I addressed your suggestions, added the operator and the rna api func.
Now to use the operator in the UI I need something like: P532. However I can't get layout from block.
Be ware that this is temporary, those options (visible/selectable/enable) are going to a real panel in the viewport, away from outliner. So I don't know if it's worthy hacking my way here, or if we simply XXX the code.
Not sure why moving away from an RNA property needs to be slow?
The operator (or regular function), can have access to all data the RNA setting has.
I mainly suggested using an operator/RNA-function as a better alternative to an RNA property.
If using an operator is slow/complicated a regular C function is fine too, outliner is one of the few places in Blender that didn't move to using operators so much.
We could check on giving operators access to tselem & te, to help moving to operators.
At the moment I don't see this as being a priority.
@Campbell Barton (campbellbarton) the slow part was coming from getting the scene layer from collection, and then getting collection id for scene layer. This was running for every collection.
It's not necessarily slow, there is only too many collections a user will have. But it's running as part of the UI code, and I think it doesn't justify.
The current approach is a good compromise in my humble opinion.
I need to make eevee and Cycles to make the distinction between visible and "disabled collection", and change depsgraph flag flushing to take this in consideration as well.
But I would prefer to do it separately from this patch, and after merging.