In case the property is a RNA pointer, `RNA_path_resolve()` will try to
resolve it and return that pointer, instead of returning expected
container... That is a bad inconsistency in the rNA path API, but no
proper way to solve it for now...
The old layout of `PointerRNA` was confusing for historic reasons:
```
typedef struct PointerRNA {
struct {
void *data;
} id;
struct StructRNA *type;
void *data;
} PointerRNA;
```
This patch updates it to:
```
typedef struct PointerRNA {
struct ID *owner_id;
struct StructRNA *type;
void *data;
} PointerRNA;
```
Throughout the code base `id.data` was replaced with `owner_id`.
Furthermore, many explicit pointer type casts were added which
were implicit before. Some type casts to `ID *` were removed.
Reviewers: brecht, campbellbarton
Differential Revision: https://developer.blender.org/D5558
This reverts commits 54fd8176d7, 4c5becb6b1 and 8f578150e.
Those kind of commits must be reviewed and approved by project owners.
That one:
* Broke Collada building by not properly updating all calls to modified
function.
* Broke *whole* ID management by not properly updating library_query.c.
And in general, I am strongly against backward ID pointers, those are
*always* a serious PITA for ID management. Sometimes they cannot be
avoided, but in general other ways to get that kind of info should be
investigated first.
NodeTree structures of materials and some other data blocks are
effectively node group data block objects that are contained inside
the parent block. Thus, direct references to them are only valid
while blender is running, and are lost on save.
Fix Copy As New Driver to create a reference that goes through
the owner data block, by adding a new runtime field to bNodeTree.
Previously there was already "draw_shape" property,
but it was doing nothing. This commit renames the
property to "display_shape". Furthermore, different
shapes like SQUARE and DIAMOND are supported now.
Currently, the shapes are drawn using the shader that also
draws keyframes. In the future we might want to separate
this.
The new shapes are not used anywhere yet, but they can
be used by addon developers and will probably be useful
when we want to support different kinds node systems later.
For example, different shapes can be used to distinguish
between data and control flow.
Differential Revision: https://developer.blender.org/D2829
This hack would make operator (push down) buttons without icons align
their text to the left in toolbars. Everywhere else in Blender, we
center it by default.
We barely use operator buttons in toolbars anymore. Even if we do and
there's a good reason to make text left aligned, it's better to use
`uiLayout.alignment = 'LEFT'` to achieve the same effect, but without
lowish-level hacks for a specific region type.
Differential Revision: https://developer.blender.org/D5527
This operator only existed to be able to see multiple reports, now instead the
info log can be opened and contents can be copy/pasted.
Patch by Valentin (Poulpator)
Differential Revision: https://developer.blender.org/D5510
Draw all constraint icons and enable/disable restrict buttons.
The action constraint needs its own icon. It currently draws white
instead of the blue modifier color.
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.
- When no change is performed on a float button, cancel the action.
- Move left/right clicks into the same block.
- Replace ambiguous names: temp, tempf.
Just enable some commented-out code from rB636289b755f6ce (disabled at
that time because we were too close of 2.79 release...).
Issue raised in D5486, thanks.
When a button represents the whole array (e.g. color picker buttons),
these context menu options were available, but didn't really work
correctly. Since it's not clear how they could reasonably work without
a valid index, it's better to hide them.
To fully support storing colors as a custom property, it is necessary
to allow switching the property UI to the standard color picker button.
That means in effect supporting custom property subtype values.
Change RNA_property_subtype to look for a 'subtype' string field
in _RNA_UI and parse it as an enum value. To minimize performance
impact, only do it if the property is an array; also, don't use
the custom subtype during RNA path parsing.
On the python side, allow setting some most useful seeming values
from the custom property settings editor.
Also, since some color picker code seems to run into a risk of
buffer overruns if the array size is wrong, check the size in
the UI layout code to be safe.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D5475
In some rare cases it is convenient to store a short array value
as a custom property, e.g. a vector or color. For example, it may
be helpful when importing/exporting certain formats that support
custom or nonstandard attributes on objects.
The custom property storage already can handle arrays in order to
support properties defined via python. The only thing missing is
UI support (and some bugs), and this patch fixes that:
- Allow editing short array properties via Custom Properties panel.
- Fix a UI layout sizing bug triggered by the previous item.
- Fix a dependency graph bug with drivers using such properties.
- Make RNA_*_get_default_array code robust in case of size mismatch.
- Support custom default values for array properties, allowing
both an array and a scalar value.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D5457
Very annoying that this whole UI thingy uses its own cooking... This is
more a quick-slap fix than a proper solution, would expect it to work in
nearly all cases though...
It is a very common need to create drivers that set the value of
a property to the value of some other property, but it currently
requires multiple actions: Copy Data Path on the input property,
adding a driver to the output property, selecting the input ID
reference, and pasting the path.
This adds a new Copy As Driver context menu option, which creates
a complete driver in the clipboard that reads the current property,
so all that remains is to paste it to the output property. It is
also possible to paste just the new driver variable into an existing
driver to combine multiple inputs.
Reviewers: brecht, billreynish
Differential Revision: https://developer.blender.org/D5382
This reverts commit 7761657129.
This commit broke overlapping popovers. For example in the color
management tab it would be impossible to select and of the popover
alternatives as it would switch to the menu button under the cursor.
We would not take into account the user "Zoom Axis" setting in certain
2D space viewports. In addition to this, the "Scale Zoom" didn't work
consistently in these spaces either.
Reviewed By: Brecht
Differential Revision: http://developer.blender.org/D5132
This change ensures that operators which needs access to evaluated data
first makes sure there is a dependency graph.
Other accesses to the dependency graph made it more explicit about
whether they just need a valid dependency graph pointer or whether they
expect the graph to be already evaluated.
This replaces OPTYPE_USE_EVAL_DATA which is now removed.
Some general rules about usage of accessors:
- Drawing is expected to happen from a fully evaluated dependency graph.
There is now a function to access it, which will in the future control
that dependency graph is actually evaluated.
This check is not yet done because there are some things to be taken
care about first: for example, post-update hooks might leave scene in
a state where something is still tagged for update.
- All operators which needs to access evaluated state must use
CTX_data_ensure_evaluated_depsgraph().
This function replaces OPTYPE_USE_EVAL_DATA.
The call is generally to be done in the very beginning of the
operator, prior other logic (unless this is some comprehensive
operator which might or might not need access to an evaluated state).
This call is never to be used from a loop.
If some utility function requires evaluated state of dependency graph
the graph is to be passed as an explicit argument. This way it is
clear that no evaluation happens in a loop or something like this.
- All cases which needs to know dependency graph pointer, but which
doesn't want to actually evaluate it can use old-style function
CTX_data_depsgraph_pointer(), assuming that underlying code will
ensure dependency graph is evaluated prior to accessing it.
- The new functions are replacing OPTYPE_USE_EVAL_DATA, so now it is
explicit and local about where dependency graph is being ensured.
This commit also contains some fixes of wrong usage of evaluation
functions on original objects. Ideally should be split out, but in
reality with all the APIs being renamed is quite tricky.
Fixes T67454: Blender crash on rapid undo and select
Speculation here is that sometimes undo and selection operators are
sometimes handled in the same event loop iteration, which leaves
non-evaluated dependency graph.
Fixes T67973: Crash on Fix Deforms operator
Fixes T67902: Crash when undo a loop cut
Reviewers: brecht
Reviewed By: brecht
Subscribers: lichtwerk
Maniphest Tasks: T67454
Differential Revision: https://developer.blender.org/D5343
Use explicit boolean flag to indicate whether flush to original data
is needed or not. Makes it possible to avoid confusion on whether an
evaluated or any depsgraph can be passed to the API.
Allows to remove depsgraph from bAnimContext as well.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D5379
It was used to access evaluated object and pose and was done prior
to implementation of flushing values back to original data for an
active dependency graph.
Removing the argument allows to simplify API and solve issues with
accessing missing dependency graph on redo.
The issue was that the redo panel area would call with region type HUD (not WINDOW).
Now we make sure that the redo panel always polls the operator in the original area type context.
Reviewed By: Brecht
Differential Revision: http://developer.blender.org/D5361
This is useful when popovers are launched from operators
instead of as button popover types.
Where the connection between the button and the popover is useful to keep.
The amount of triangles drawn by the button depends on its `sizex`.
See:
```
immBegin(GPU_PRIM_TRI_STRIP, (sizex + 1) * 2);
```
Therefore the `sizex` cannot be 0.
Solution a bit similar to rB56b0cd1d.
Ref T67671
Reviewers: fclem, brecht
Maniphest Tasks: T67671
Differential Revision: https://developer.blender.org/D5347
