Page MenuHome

fix preserving user selected exclude-state of nested collections.
Needs ReviewPublic

Authored by Dirk Wallenstein (d-egg) on Dec 14 2020, 2:59 PM.

Details

Summary

Exclude from view-layer state is not preserved across multiple nesting levels in the outliner

In the example:

  • turn off widget1
  • toggle theme off and on again
  • turn on widget1
  • notice that the collection exclude-state is gone.

Rewrite the implementation of setting the corresponding flags by focusing on maintaining the synced state of those two flags and trying to make complex logic a bit more intuitive.

Regarding the behavior: excluding from view layer works like a one time ad-hoc curtain thrown over the nested items. When unveiling the explicitly chosen state gets restored.

Diff Detail

Repository
rB Blender
Branch
collectionstate (branched from master)
Build Status
Buildable 11780
Build 11780: arc lint + arc unit

Event Timeline

Dirk Wallenstein (d-egg) requested review of this revision.Dec 14 2020, 2:59 PM
Dirk Wallenstein (d-egg) created this revision.

Subject: [PATCH] Outliner: Rewrite exclude flag toggling

There are two exclude flags. One describes the current display state,
and the other tracks the user-chosen state for that element. Toggling
the directly controlled element does either hide all elements beneath,
or restore the previous state of those recursive elements.

IOW: excluding from view layer works like an ad-hoc curtain over all
nested elements. While un-excluding unveils recursively up to children
that the user chose to deliberately exclude. All else would be another
view layer.

Guarantee to keep flags in sync by extracting setting those into
a separate function.

This reworks f3433fcd3bf87c9405fb05c96fde036eb658e8aa but keeps that behavior. Adding mentioned developers.

This comment was removed by Dirk Wallenstein (d-egg).

Demo for the problem it fixes

The new function is certainly not required

Hans Goudey (HooglyBoogly) requested changes to this revision.Jan 26 2021, 7:36 PM

Thanks for the patch! The current behavior can be annoying, I agree.

Could you remove the detailed steps to reproduce the problem from the patch description? Since they're already in the bug report there's no need to duplicate them here. A higher-level description of the problem would be better for a commit message.

Two small code style things:

  1. Please use clang format on the patch.
  2. Comments should always begin with a capital letter and end with a period. Also I think it's more common not to put them on the same lines as the "if" and "else" statements.
This revision now requires changes to proceed.Jan 26 2021, 7:36 PM

I slimmed down the comments a bit more. I understand that comments can get
stale, and they might describe stuff that is obvious to people familiar with
the source. I might not have the sense for that. Feel free to truncate more.

Oh, clang-format was easier than I thought. I didn't expect that the entire
source is actually in that format. :)

I slimmed down the comments a bit more. I understand that comments can get
stale, and they might describe stuff that is obvious to people familiar with
the source. I might not have the sense for that. Feel free to truncate more.

Oh, clang-format was easier than I thought. I didn't expect that the entire
source is actually in that format. :)

Thanks! Yeah, clang format is great. I'll leave the rest of the review to others since I don't have much experience in this area.