| Age | Commit message (Collapse) | Author |
|---|
|
With libepoxy we can choose between EGL and GLX at runtime, as well as
dynamically open EGL and GLX libraries without linking to them.
This will make it possible to build with Wayland, EGL, GLVND support while
still running on systems that only have X11, GLX and libGL. It also paves
the way for headless rendering through EGL.
libepoxy is a new library dependency, and is included in the precompiled
libraries. GLEW is no longer a dependency, and WITH_SYSTEM_GLEW was removed.
Includes contributions by Brecht Van Lommel, Ray Molenkamp, Campbell Barton
and Sergey Sharybin.
Ref T76428
Differential Revision: https://developer.blender.org/D15291
|
|
|
|
No user visible changes expected.
We have a bunch of "base" element types, just to show a label element
for grouping together other elements. There is no reason to have these
tied to a case, just have a generic label type for this. It requires a
string to display, and can display an icon too. The new element type
isn't used yet, but will be in one of the following commits. Would be
nice if the existing base elements can be replaced by this.
Part of D15606.
|
|
(Not meant to cause user visible changes.)
Adds some first new iterators to traverse over tree elements with a
functional syntax. Functional because it meant to be used with C++
lambdas.
For example, this common pattern:
```lang=cpp
void some_recursive_function(SpaceOutliner *space_outliner, ListBase *tree, ...)
{
LISTBASE_FOREACH (TreeElement *, te, tree) {
/* ... do something with the element ... */
/* Recurse into open children. */
if (TSELEM_OPEN(TREESTORE(te), space_outliner) {
some_recursive_function(&te->subtree, ...);
}
}
}
```
Gets simplified to this:
```lang=cpp
void some_function(SpaceOutliner &space_outliner, ...)
{
tree_iterator::all_open(space_outliner, [&](TreeElement *te) {
/* ... do something with the element ... */
});
}
```
We can add more iterators, e.g. some that support early exiting or
skipping children, returning a custom type, only act on selected
elements, etc.
The following commit will convert a bunch of code to use these. Some
further benefits will become visible there. Not all cases are straight
forward to convert, but hopefully more and more code can be refactored
to work with this. This deduplicates and centralizes the iteration
logic, which will later make it much easier to refactor how the tree
storage is done (e.g. move it to `SpaceOutliner_Runtime` and use a
better container than `ListBase`).
|
|
Uses a inheritance based approach for querying warning of tree elements
and the mode column support of display modes.
For the warnings, tree elements can override the
`AbstractTreeElement::getWarning()` method and return a warning string.
The UI will draw the warning column with warning icons. This makes the
warning column more generalized and easier to extend to more use-cases.
E.g. library override elements will use this after a followup commit.
To support mode toggles a display mode can now just return true in the
`AbstractTreeDisplay::supportsModeColumn()` method. This makes it
trivial to add mode columns to other display modes, and less error prone
because there's no need to hunt down a bunch of display mode checks in
different places.
|
|
|
|
Adds a dropdown for the Library Overrides display mode that lets users
choose between a "Properties" and a "Hierachies" view mode. The former
is what was previously there (a mode that displays all overridden
properties with buttons to edit the values), the latter is new. It
displays the hierarchical relationships between library overridden
data-blocks. E.g. to override the mesh of an object inside a linked
collection, the entire collection > object > mesh hierarchy needs to be
overridden (whereby the former two will be automatically overridden
using system overrides).
The Hierarchies mode will also show the override hierarchies of
data-blocks that were linked and are overridden in the source file. This
information is useful to have, especially for debugging scenes.
Part of T95802.
Differential Revision: https://developer.blender.org/D14440
Reviewed by: Bastien Montagne
|
|
Lets `makesrna` generate a `RNA_prototypes.h` header with declarations for all
RNA properties. This can be included in regular source files when needing to
reference RNA properties statically.
This solves an issue on MSVC with adding such declarations in functions, like
we used to do. See 800fc1736748. Removes any such declarations and the related
FIXME comments.
Reviewed By: campbellbarton, LazyDodo, brecht
Differential Revision: https://developer.blender.org/D13837
|
|
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
|
|
Previously, macros were ifdefed using the cmake option `WITH_INTERNATIONAL`
However, the is unnecessary as withen the functions themselves have checks for building without internationalization.
This also means that many `add_definitions(-DWITH_INTERNATIONAL)` are also unnecessary.
Reviewed By: mont29, LazyDodo
Differential Revision: https://developer.blender.org/D13929
|
|
Continuation of work started in 2e221de4ceee and 249e4df110e0.
Adds new tree-element classes for sequences, strips and strip
duplicates.
|
|
Continuation of work started in 2e221de4ceee and 249e4df110e0.
Adds new tree-element classes for RNA structs, properties and array
elements. This isn't exactly a copy and paste, even though logic should
effectively be the same. Further cleanups are included to share code in
a nice way, improve code with simple C++ features, etc.
|
|
Basically this removes any C <-> C++ glue code. C++ types are accessed
directly via the public C++ APIs.
Contains some related changes like, moving functions that were
previously declared in a now removed header to a different file, whose
header is the more appropriate place (and the source file as well).
But generally I tried to avoid other changes.
|
|
We want to refactor quite some of the Outliner code using C++, this is a
logical step to help the transition to a new architecture.
Includes plenty of fixes to make this compile without warnings, trying
not to change logic. The usual stuff (casts from `void *`, designated
initializers, compound literals, etc.).
|
|
This is a minimal, information-only view currently, listing by default
all the override data-blocks, with their user-edited override
properties.
System-generated overrides (like the overrides of pointers to other
override data-blocks) can be shown through a filter option.
Finally, potential info or warning messages from (auto-)resync propcess
are also shown, as an icon + tooltip next to the affected items.
Part of D10855.
|
|
Fairly straight forwards.
Also fixes the bug from recent refactor that would not show overrides as
a tree, but as a flat list directly under IDs.
|
|
Splits up `tree_element_id.cc`/`tree_element_id.hh`.
If we move all ID types into this one file, it will become rather big. Smaller
files are probably easier to work with. We could still keep small classes like
`TreeElementIDLibrary` in the general file, don't mind really, but this creates
separate files for that too.
|
|
These files can contain more than just the "base" tree element types. E.g. the
class for the view-layer base element can also contain the class for the
view-layer elements. Otherwise we'd end up with like >50 files for the
individual types, most of them very small.
So just give the files a general name and put the related classes in there.
|
|
code design
Continuation of work in 2e221de4ceee, 249e4df110e0 and 3a907e742507.
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 2e221de4ceee and 249e4df110e0 .
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
e0442a955bad.
|
|
Continuation of work in 2e221de4ceee and 249e4df110e0. Now the tree-element
types have to be ported one by one. This is probably the most straight forward
type to port.
|
|
As discussed in D10301.
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D10303
|
|
The way the Outliner integrates operations on selected tree elements is known
to be quite problematic amongst developers. The context menu is generated in an
unusual way and doesn't use the normal operator system. Instead, changes are
applied via a recursive callback system. Things are quite ad-hoc, and the
callbacks often implement logic that should not be in the Outliner, but in
entirely different modules. Often these modules already contain the logic, but
as proper operators.
This commit is a step into a hopefully better direction that should allow us to
put actual operators into Outliner context menus. It starts solving the problem
of: How can the Outliner pass selected data to operators. It implements it for
data-blocks only, but other data could do it in the same way.
Idea is to keep doing what operators were initially designed to do: Operate on
context.
Operators can now query a "selected_ids" context member
(`CTX_data_selected_ids()` in C, `bpy.context.selected_ids` in .py). If an
Outliner is active, it will generate a list of selected data-blocks as a
response, via its `SpaceType.context` callback.
Any other editor could do the same.
No user visible changes. This new design isn't actually used yet. It will be
soon for asset operators.
Reviewed as part of https://developer.blender.org/D9717.
Reviewed by: Brecht Van Lommel
|
|
|
|
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.
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.
|
|
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.
|
|
This is first step of refactoring task T77580.
Next step will be breaking up files into smaller ones.
Reviewed By: sergey, brecht
Differential Revision: https://developer.blender.org/D8492
|
|
|
|
Adds a toggle to the filter menu for outliner synced selection. Enabled
by default, this ensures selection is synced between objects, bones, and
sequences. An active outliner element theme color is added to indicate
which element is active.
Synced selection is controlled on the operator level. Each operator
that modifies selection for objects, bones, sequences, or outliner
elements needs to call the respective ED_outliner_select_sync_from..
function to tag outliners to be synced.
Syncing is done lazily on outliner draw.
|
|
|
|
Apply clang format as proposed in T53211.
For details on usage and instructions for migrating branches
without conflicts, see:
https://wiki.blender.org/wiki/Tools/ClangFormat
|
|
Tested to work on Linux and macOS.
This will be enabled once all platforms are verified.
See D4684
|
|
No functional change, this adds LIB definition and args to cmake files.
Without this it's difficult to migrate away from 'BLENDER_SORTED_LIBS'
since there are many platforms/configurations that could break when
changing linking order.
Manually add and enable WITHOUT_SORTED_LIBS to try building
without sorted libs (currently fails since all variables are empty).
This check will eventually be removed.
See T46725.
|
|
Following removal from C source code.
See: 8c68ed6df16d8893
|
|
|
|
BKE_depsgraph.h
This removes BKE_depsgraph.h and depsgraph.c
|
|
|
|
This reverts commit 3da834e83ce9d7056c033148dab04885a6d3b1b7.
We will use the outliner for this now.
I'm also moving the collections_ops.c to outliner_collections.c
|
|
- Add blentranslation `BLT_*` module.
- moved & split `BLF_translation.h` into (`BLT_translation.h`, `BLT_lang.h`).
- moved `BLF_*_unifont` functions from `blf_translation.c` to new source file `blf_font_i18n.c`.
|
|
https://developer.blender.org/D643
Separates graphics context creation from window code in Ghost so that they can vary separately.
|
|
|
|
remove MEM_sys_types.h which was a duplicate.
|
|
among which:
* Drag'n'drop translation in Outliner
* "Execute" button in file window
* "Labels" of spacing elements, in multi-column enums
* A glitch with nodes "Value to RGB", they where called "ColorRamp" in node_type_base() call. This is not definitive, though, as it appears that UI node names are determined by this call, while it should be by "defines" in rna_nodetrre_types.h, I guess... Anyway, not good to have such things in two different places!
Also moved default context name under BLF_translation.h, much better to have those all in one place, accessible from whole Blender code!
|
