The main simplification is using return values rather than return
arguments, and the additional semantic clarity from std::optional.
Also use `fmt` for formatting and use lambdas instead of macros
as helpers in a few modal keymap formatting functions.
Similar commits:
- a1792e98a4
- f04bc75f8c
- 6abf43cef5
- 7ca4dcac5a
Pull Request: https://projects.blender.org/blender/blender/pulls/117785
Reloading scripts lead to wmDropBox::ot pointing to freed operators.
Resolve by following the logic of key-map operator initialization
to ensure changes to registered operator triggers a refresh of the
operator pointer & properties.
Also add null pointer check not to assume wmKeyMapItem::properties
implies an allocated wmKeyMapItem::ptr. Something which is already
accounted for everywhere else.
Regression from [0] where the key-map was attempting to load preferences
for key-map items for add-on operators which were not yet defined.
Resolve by postponing keymap updating until after loading add-ons.
[0]: 6de294a191
Regression caused by [0]. Resolve by adding a 'keep_properties' argument
to KeyConfig.update so the key-map items can be restored after the
operators have been reloaded.
[0]: 88a875ec3a
Regression caused by [0]. Resolve by adding a 'keep_properties' argument
to KeyConfig.update so the key-map items can be restored after the
operators have been reloaded.
[0]: 88a875ec3a
`Restore item` button is not resetting `active` property when keyitem is registered
as `inctive` by default. To fix this, clear `inactive` flag then use default keyitem's
flag to correctly restore the keyitem.
Pull Request: https://projects.blender.org/blender/blender/pulls/112497
There were enough cases of callers ignoring a potential the error value,
using the column width for e.g. to calculate pixel sizes, or the size in
bytes to calculate buffer offsets.
Since text fields & labels can include characters that return an error
from BLI_str_utf8_as_unicode, add the suffix to make this explicit.
Since [0] modal transform in the 3D viewport caused key-maps to be
rebuilt by the event system. Creating a temporary copy for
ViewOpsData_Utility flagged the key-map as outdated.
This could crash (resolved by [1] - for the most-part), but would still
rebuild the whole key-map, adding unnecessary overhead.
This would also reset the KMI_EXPANDED flag, causing transform
to hide key-map items when using Blender with the key-map editor open.
Add a function to temporarily suppress key-map updates.
While not ideal, full support for temporary key-maps that behave
differently to user key-maps is a bigger project for something
that's only needed in one place.
[0]: 017d4912b2
[1]: 9a0eaa2062
Any action that triggered the key-map to be rebuilt causes the key-map
UI to display freed data.
Recently key-map refreshing happens during transform, while this should
be resolved - it's still good to avoid a crash in this situation as it's
possible scripts perform actions that tag the key-map to be rebuilt
which is out of our control.
C++ callers must ensure the arguments are valid,
reserve validity for the RNA API for raising errors.
This is already the case for most RNA API calls that wrap BKE API's.
There are a couple of functions that create rna pointers. For example
`RNA_main_pointer_create` and `RNA_pointer_create`. Currently, those
take an output parameter `r_ptr` as last argument. This patch changes
it so that the functions actually return a` PointerRNA` instead of using
the output parameters.
This has a few benefits:
* Output parameters should only be used when there is an actual benefit.
Otherwise, one should default to returning the value.
* It's simpler to use the API in the large majority of cases (note that this
patch reduces the number of lines of code).
* It allows the `PointerRNA` to be const on the call-site, if that is desired.
No performance regression has been measured in production files.
If one of these functions happened to be called in a hot loop where
there is a regression, the solution should be to use an inline function
there which allows the compiler to optimize it even better.
Pull Request: https://projects.blender.org/blender/blender/pulls/111976
Listing the "Blender Foundation" as copyright holder implied the Blender
Foundation holds copyright to files which may include work from many
developers.
While keeping copyright on headers makes sense for isolated libraries,
Blender's own code may be refactored or moved between files in a way
that makes the per file copyright holders less meaningful.
Copyright references to the "Blender Foundation" have been replaced with
"Blender Authors", with the exception of `./extern/` since these this
contains libraries which are more isolated, any changed to license
headers there can be handled on a case-by-case basis.
Some directories in `./intern/` have also been excluded:
- `./intern/cycles/` it's own `AUTHORS` file is planned.
- `./intern/opensubdiv/`.
An "AUTHORS" file has been added, using the chromium projects authors
file as a template.
Design task: #110784
Ref !110783.
Using ClangBuildAnalyzer on the whole Blender build, it was pointing
out that BLI_math.h is the heaviest "header hub" (i.e. non tiny file
that is included a lot).
However, there's very little (actually zero) source files in Blender
that need "all the math" (base, colors, vectors, matrices,
quaternions, intersection, interpolation, statistics, solvers and
time). A common use case is source files needing just vectors, or
just vectors & matrices, or just colors etc. Actually, 181 files
were including the whole math thing without needing it at all.
This change removes BLI_math.h completely, and instead in all the
places that need it, includes BLI_math_vector.h or BLI_math_color.h
and so on.
Change from that:
- BLI_math_color.h was included 1399 times -> now 408 (took 114.0sec
to parse -> now 36.3sec)
- BLI_simd.h 1403 -> 418 (109.7sec -> 34.9sec).
Full rebuild of Blender (Apple M1, Xcode, RelWithDebInfo) is not
affected much (342sec -> 334sec). Most of benefit would be when
someone's changing BLI_simd.h or BLI_math_color.h or similar files,
that now there's 3x fewer files result in a recompile.
Pull Request #110944
No user visible changes expected, except of new experimental feature
option.
------------------------------------------------------------------------------
This introduces asset shelves as a new standard UI element for accessing
assets. Based on the current context (like the active mode and/or tool), they
can provide assets for specific workflows/tasks. As such they are more limited
in functionality than the asset browser, but a lot more efficient for certain
tasks.
The asset shelf is developed as part of the brush assets project (see #101895),
but is also meant to replace the current pose library UI.
Support for asset shelves can quite easily be added to different editor types,
the following commit will add support for the 3D View. If an editor type
supports asset shelves, add-ons can chose to register an asset shelf type for
an editor with just a few lines of Python.
It should be possible to entirely remove `UILayout.asset_view_template()` once
asset shelves are non-experimental.
Some changes are to be expected still, see #107881.
Task: #102879
Brush asset workflow blog post: https://code.blender.org/2022/12/brush-assets-workflow/
Initial technical documentation: https://developer.blender.org/docs/asset_system/user_interface/asset_shelf/
Pull Request: #104831
