In blender.chat, @Ivan Cappiello (icappiello) wrote:

i think it address a limitation and it's very welcome. I am always a bit worried about general design of the tool. Here at MAD Rigify it's used also (and mostly) by non riggers but by expert riggers as well. There's always a great struggle between the idea of a magic button and a clear statement of what exactly happened when you clicked the button. We always try to design the tool to keep both (casual rigger and rigging TD) experiences in count.
I have some concerns about rigify dealing with more than just the armature itself.
For example, here we have random crashes exiting local view mode. It happens very often but randomly, so i can't open a report. But it happens. If rigify triggers a local view, and the local view crashes blender, it would be really tricky to find the issue, and moreover if the culprit is rigify itself or the local view code.
I use this case as just an example of why this seems to me an hack way of doing it. It's probably a needed upgrade, but would be better to restrict its interactions to just the two involved object visibility (and even there, there could be problems dealing with users customs like driver on visibility states and so on).
so what we came up with previous rigify design is to have this potentially useful, but more edgy cases, features like toggle options (see "advanced options" menu). This way the user is aware of the fact that rigify is doing something different than elementary rig generation and we can restrict the case if that feature raise troubles because the basic rig generation process stays untouched

Your feedback is very welcome, I wouldn't want to make changes to Rigify without your approval, and I think you make great points.

But I would like to take a stab at re-defining the issue you're raising:

1. It might actually be confusing for a user who doesn't entirely know what they are doing, if rig generation succeeded even though the target rig is hidden. After all, they won't see any change on their screen.
2. Calling local view operator can be crash-prone.

So I would make the following changes:

1. Don't re-hide the target rig after generation. Simply, if it was hidden, unhide it, and leave it un-hidden. No longer support the case where the rig is in a disabled collection: This would still fail, but with a useful error message: "Target rig is in a disabled collection, could not generate".
2. Avoid exiting local view. Instead, the target rig can be brought into local view safely, without bpy.ops. I already do this in some other code I have which I know to be stable, I just need to check out how I was doing it.

Not having to mess around with collections would also avoid accessing the global context, as pointed out by Sybren via chat.

Based on feedback from Bassam and Luciano in today's animation module meeting, I will be making the following changes when I find the time:

• When the target rig is hidden but can be made visible with the eye or screen icons, do that and do not restore its visbility to original state.
• When the target rig is hidden and cannot be made visible with the eye or screen icons, fail early with an error explaining that the rig is in a hidden collection, therefore cannot be generated.