There was an implicit assumption that tree element types using the new code
design set their name on creation. Use an assert to make this explicit. See
f59ff9e03a, which was an error because of this broken assumption.
Continuation of work in 2e221de4ce, 249e4df110 and 3a907e7425.
Adds new tree-element classes for the scene-ID, scene collections, scene
objects, and the view layers base.
There is some more temporary stuff in here, which can be removed once we're
further along with the porting. Noted that in comments.
Continuation of work in 2e221de4ce and 249e4df110 .
This prepares things so we can start porting the individual ID types to
the new code design. I already added some code for library IDs, because
they need some special handling during construction, which I didn't want
to break.
The `AbstractTreeElement::isExpandValid()` check can be removed once
types were ported and can be assumed to have a proper `expand()`
implemenation.
Also makes `TreeElementGPencilLayer` `final` which I forgot in
e0442a955b.
Code to check if the Outliner tree-element type was the general ID one
would always check against "0" (explicity or even implicitly). For
somebody unfamiliar with the code this is very confusing. Instead the
value should be given a name, e.g. through an enum.
Adds `TSE_SOME_ID` as the "default" ID tree-element type. Other types
may still represent IDs, as I explained in a comment at the definition.
There may also still be cases where the type is checked against "0". I
noted in the comment that such cases should be cleaned up if found.
Continuation of work in 2e221de4ce and 249e4df110. Now the tree-element
types have to be ported one by one. This is probably the most straight forward
type to port.
It is perfectly 'valid' to find invalid RNA properties references in
override properties list. Data change, RNA changes, IDProperties change,
some linked ID may become unavailable, etc.
Note that those invaldi override properties are cleaned up when updating
the override info (so typically on undo step storage, and .blend file save).
Having a centeral place to find a list of all library overrides should be
useful for managing production scenes where library overrides are used a lot.
This change adds the individually overridden properties of a data-block under
the data-block itself. Just how we show modifiers, constraints or pose channels
there. This way we can also expose library override operations/options better
in future.
There's also a filter option for the library overrides now, so they can be
hidden. It is only available in the View Layer display mode though, like the
other filter options.
One internal change this has to do is adding more informative return values to
undo pushes and the library override functions called by it. That way we can
send a notifier when library overrides change for the Outliner to know when to
rebuild the tree.
Differential Revision: https://developer.blender.org/D7631
Reviewed by: Andy Goralczyk, Bastien Montagne, William Reynish
Continuation of the work started with 249e4df110. After all display modes
were ported to this new design, this commit starts the (more complex) work on
the individual tree-element types. More concretely it ports animation
tree-elements (action data-blocks, drivers and NLA data).
The commit above explains motivations. In short, we need a better design that's
easier to reason about and better testable.
Changes done here are pretty straight forward and introduce similar class
hierarchy and building patterns as introduced for the display modes already.
I.e. an abstract base class, `AbstractTreeElement` with derived classes for the
concrete types, and a C-API with a switch to create the needed objects from a
type enum. The latter should be replacable with something nicer later on (RAII
based, and type-safer through meta-programming).
Each tree-element type has its own class, with an own header and source file
(okay some closely related types can share a header and source file, like the
NLA ones).
I added some further temporary bits for the transition to the new design, such
as the `TreeElement.type`. It should entirely replace `TreeElement` eventually,
just as `outliner_add_element()` should be quite small by then and easily
replacable by a `TreeBuilder` helper.
I carefully checked and am quite sure for `TSE_ANIMATION_DATA` and
`TSE_NLA_ACTION` the direct-data isn't used at all. This data is stored and
accessed in unsafe ways based on conventions anyway (`void *`). We should aim
for a safer design but it will be difficult to get there. Any removed
complexity will help.
Non-ID tree-elements would cast their data pointer to `ID *` and take the name
and ID-Code from there. The name would actually be overridden a few lines
later, so that didn't cause issues. But the ID-Code stored inside the tree
element kept an undefined value. In practice that probably didn't cause many
issues either, since it's just an undefined value that was very unlikely to
take a valid 16-bit ID-code value, meaning ID-Code checks would simply fail as
they should. Further there typically are other checks to see if the element
actually represents an ID.
However, in theory this may have caused a few random crashes or
data-corruptions.
No functional changes. This is a few minor cleanups to the remaining C
code for building the outliner tree after parts have been moved to C++.
Differential Revision: https://developer.blender.org/D9741
No functional changes. Code is ported to C++ with additional cleanups to
the logic and variable names.
Differential Revision: https://developer.blender.org/D9741
This way Outliner internal data stays internal, non-Outliner code will not be
able to access and mess with this. Further it allows us to use the real type
(rather than `void *`), change the type to a C++ container if needed and
slightly reduces the size for every Outliner stored in files.
Slightly changed how we set the `SO_TREESTORE_REBUILD` for this, but it should
effectively behave the same way as before.
This adds an invert toggle for the outliner object state filters.
There are some cases where we want a filter for invertable states (Selected,
Unselected) and having a single toggle to invert the filter reduces the
number of separate filter types needed. This removes the "Hidden" filter
which can now be replicated with an inverted "Visible" filter.
Differential Revision: https://developer.blender.org/D9598
See https://developer.blender.org/D9499.
It's odd to include a C++ header (".hh") in C code, we should avoid that. All
of the Outliner code should be moved to C++, I don't expect this C header to
stay for long.
See https://developer.blender.org/D9499.
"View" leads to weird names like `TreeViewViewLayer` and after all they are
specific to what we call a "display mode", so "display" is more appropriate.
Also add, update and correct comments.
See https://developer.blender.org/D9499.
Also:
* Add `space_outliner/tree/common.cc` for functions shared between display
modes.
* I had to add a cast to `ListBaseWrapper` to make it work with ID lists.
* Cleanup: Remove internal `Tree` alias for `ListBase`. That was more confusing
than helpful.
See https://developer.blender.org/D9499.
* Turn functions into member functions (makes API for a type more obvious &
local, allows implicitly sharing data through member variables, enables order
independend definition of functions, allows more natural language for
function names because of the obvious context).
* Move important variables to classes rather than passing around all the time
(shorter, more task-focused code, localizes important data names).
* Add helper class for adding object children sub-trees (smaller, more focused
units are easier to reason about, have higher coherence, better testability,
can manage own resources easily with RAII).
* Use C++ iterators over C-macros (arguably more readable, less macros is
generally preferred)
* Add doxygen groups (visually emphasizes the coherence of code sections,
provide place for higher level comments on sections).
* Prefer references over pointers for passing by reference (makes clear that
NULL is not a valid value and that the current scope is not the owner).
This introduces a new C++ abstraction "tree-display" (in this commit named
tree-view, renamed in a followup) to help constructing and managing the tree
for the different display types (View Layer, Scene, Blender file, etc.).
See https://developer.blender.org/D9499 for more context. Other developers
approved this rather significantly different design approach there.
----
Motivation
General problems with current design:
* The Outliner tree building code is messy and hard to follow.
* Hard-coded display mode checks are scattered over many places.
* Data is passed around in rather unsafe ways (e.g. lots of `void *`).
* There are no individually testable units.
* Data-structure use is inefficient.
The current Outliner code needs quite some untangling, the tree building seems
like a good place to start. This and the followup commits tackle that.
----
Design Idea
Idea is to have an abstract base class (`AbstractTreeDisplay`), and then
sub-classes with the implementation for each display type (e.g.
`TreeDisplayViewLayer`, `TreeDisplayDataAPI`, etc). The tree-display is kept
alive until tree-rebuild as runtime data of the space, so that further queries
based on the display type can be executed (e.g. "does the display support
selection syncing?", "does it support restriction toggle columns?", etc.).
New files are in a new `space_outliner/tree` sub-directory.
With the new design, display modes become proper units, making them more
maintainable, safer and testable. It should also be easier now to add new
display modes.
Ensure that When checking "Hide in Viewport" option for a collection
that child objects are drawn grayed out for consistency with the
"Disable in Viewports" toggle.
For checking an object visibility in the viewport the flag
BASE_VISIBLE_VIEWLAYER should be used instead of BASE_VISIBLE_DEPSGRAPH
because the latter ignores viewport visibility.
Manifest Task: T77161
Differential Revision: https://developer.blender.org/D7904
This addition to the filters allows the user to enable the
outliner tree to restrict the listing to only Selectable objects.
Differential Revision: https://developer.blender.org/D7310
When changing the selected, active or visible object(s), the Outliner
has to be rebuilt while using the corresponding object state filters.
The object hiding operators also have to send the proper notifiers (they
changed visibility without notifying about that).
Grease pencil modifiers already had defined outliner icons, but had
never been included in the tree. This adds the modifiers and the shader
effects to the tree.
Part of T68498
We can avoid the rather expensive outliner tree rebuilds and only redraw
if nothing but the selection or active item changes. This should give a
bit of speedup for heavy scenes.
For this to work I had to correct a few notifiers, some were only
sending selection/active change notifiers that actually did things like
adding objects. I also added a more precise notifier type for when the
active collection changes. At the notifier subtype/action level we're
not even close to running out of bits, so this should be fine.
Also had to correct a wrong notifier check (was using `&` rather than
`==`).
Filtering Collections when also filtering object children would only
display the parent object. Add a check for the NO_CHILDREN filter before
creating the object-parent hierarchy.
Collection instance datablocks were not filtered out when only showing
the selected object. They were treated as a collection (which should
show when filtering objects). Adds a case to check if the parent is an
object.
No functional changes. Convert all C++ style comments to C comments.
Also capitalize and add full stops.
The comments themselves were not cleaned up. Some could be removed or
reworded.
This addresses warnings from Clang-Tidy's `readability-else-after-return`
rule in the `source/blender/editors/space_outliner` module.
No functional changes.
Steps to reproduce were:
* Load factory settings
* Link any library
* Change to "Blender File" display mode in Outliner
* Enable filtering
* -> Assert fails
This may have had further side-effects for linked IDs.
Checked with Bastien, the NULL-check seems reasonable. It was initially there
but removed in d74f9c4b7b.
Fine to backport.
