Change Details

NOTE: I do not ask for an in-depth review. This is just to make sure other devs agree on this rather significant shift in design. ##### Motivation 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 introduces a new abstraction "tree-display" to help constructing and managing the tree for the different display types (View Layer, Scene, Blender file, etc.). ##### Design Idea Idea is to have an abstract base class (`blender::ed::outliner::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. Note that this patch only converts the View Layer mode, eventually it should look like this: {F9261614} //The following sections are commit messages for further refactors I've done here.// ---- #### UI Code Quality: General refactor of Outliner View Layer display mode building * 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). ---- #### UI Code Quality: Use C++ data-structures for Outliner object hierarchy building * 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).

NOTE: I do not ask for an in-depth review. This is just to make sure other devs agree on this rather significant shift in design. ##### Motivation 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 introduces a new abstraction "tree-display" to help constructing and managing the tree for the different display types (View Layer, Scene, Blender file, etc.). ##### Design Idea Idea is to have an abstract base class (`blender::ed::outliner::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. Note that this patch only converts the View Layer and Blender File mode, eventually it should look like this: {F9261614} //The following sections are commit messages for further refactors I've done here.// ---- #### UI Code Quality: General refactor of Outliner View Layer display mode building * 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). ---- #### UI Code Quality: Use C++ data-structures for Outliner object hierarchy building * 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).

NOTE: I do not ask for an in-depth review. This is just to make sure other devs agree on this rather significant shift in design. ##### Motivation 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 introduces a new abstraction "tree-display" to help constructing and managing the tree for the different display types (View Layer, Scene, Blender file, etc.). ##### Design Idea Idea is to have an abstract base class (`blender::ed::outliner::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. Note that this patch only converts the View Layer and Blender File mode, eventually it should look like this: {F9261614} //The following sections are commit messages for further refactors I've done here.// ---- #### UI Code Quality: General refactor of Outliner View Layer display mode building * 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). ---- #### UI Code Quality: Use C++ data-structures for Outliner object hierarchy building * 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).