| Age | Commit message (Collapse) | Author |
|---|
|
API functions get SEQ_ prefix.
Intern functions get seq_ prefix
Functions also have appropriate category included in name.
|
|
|
|
Remove DNA headers, using forward declarations where possible.
Also removed duplicate header, header including it's self
and unnecessary inclusion of libc system headers from BKE header.
|
|
|
|
Continuation of the work started with 249e4df110e0. 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.
|
|
No functional changes. Moves the data API display building code to C++.
Differential Revision: https://developer.blender.org/D9741
|
|
No functional changes. The scene display building code has 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
|
|
No functional changes. Code is ported to C++. Variable names and logic
are also improved.
Differential Revision: https://developer.blender.org/D9741
|
|
|
|
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.
* Use C++17 nested namespaces.
* Use `_` suffix rather than prefix for private member variables.
Also: Simplify code visually in `tree_view.cc` with `using namespace`.
|
|
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).
* 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).
* Reduce indentation levels, use `continue` in loops to ensure preconditions
are met.
* Add asserts for sanity checks.
|
|
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.
Also remove unnecessary forward declaration.
|
|
See https://developer.blender.org/D9499.
|
|
See https://developer.blender.org/D9499.
* Add comments to explain the design ideas better.
* Follow code style guide for class layout.
* Avoid uninitialized value after construction (general good practice).
|
|
See https://developer.blender.org/D9499.
* Use `blender::Map` over `GHash`
* Use `blender::Vector` over allocated `ListBase *`
Benefits:
* Significantly reduces the amount of heap allocations in large trees (e.g.
from O(n) to O(log(n)), where n is number of objects).
* Higher type safety (no `void *`, virtually no casts).
* More optimized (e.g. small buffer optimization).
* More practicable, const-correct APIs with well-defined exception behavior.
Code generally becomes more readable (less lines of code, less boilerplate,
more logic-focused APIs because of greater language flexibility).
|
|
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.
|
