The numeric levels have no obvious meaning. This removes the distinction
between severity and levels, instead there is a single list of named levels
with defined meaning.
Debug means information that's mainly useful for developers, and trace is for
very verbose code execution tracing.
Pull Request: https://projects.blender.org/blender/blender/pulls/140244
* Remove bke, ed and wm prefixes
* Add prefixes like: geom, object, blend, lib.
* Shorten some category names
* A few log level changes to improve --log-level info output
Pull Request: https://projects.blender.org/blender/blender/pulls/140244
When selecting gizmos (such as one of the scale handles in the
Transform tool), the depth test state does not match what is shown in
the viewport. This can lead to unintuitive gizmo selection.
The issue is caused by the incorrect assumption that the depth state is
already `GPU_DEPTH_NONE` before rendering the gizmos for selection.
The solution is to ensure the status before rendering.
Pull Request: https://projects.blender.org/blender/blender/pulls/141412
This commit takes the previously defined `Paint_Runtime` struct and
moves it into the BKE namespace, initializing it on demand instead of it
being a default-allocated member. This data does not need to be
persisted and is runtime only.
Pull Request: https://projects.blender.org/blender/blender/pulls/141413
This renames `UI_block_layout` API as `blender::ui::block_layout`,
following uiLayout refactors.
This function now returns a layout reference instead of pointer,
this changes applies this return type where the layout can be used
as such reference.
Changes includes the use of `blender::ui::LayoutDirection` and
`blender::ui::LayoutType` as typed enum parameters.
Part of: #117604
Pull Request: https://projects.blender.org/blender/blender/pulls/141401
Currently drag and drop expects to selection to be in the same folder,
but blender internal file browser allows to select files from different
folders when recursion is active.
When writing to operator properties the `directory` is taken now from
the first file provided, and `files` are now relative to this
`directory` instead of just taking the file name.
When reading from operator properties filepaths are normalized.
I notice this issue while reading about #140942, the issue would
require a proper fix too.
Pull Request: https://projects.blender.org/blender/blender/pulls/140948
While calculating the scaling factor when rasterizing SVG files to
cursors there is an extra code line left in that was only used
during testing. Basically the size is correctly calculated and then
this extra line does it again, but in a different way. This can result
in the very bottom single line of the cursor being cut off at some
sizes.
Pull Request: https://projects.blender.org/blender/blender/pulls/141410
When playing back render result a separate process is started for
playback. This process didn't call the GPU_context_frame_begin/end
functions resulting in post-poning destroying discarded resources until
the playback process was 'exited'.
Pull Request: https://projects.blender.org/blender/blender/pulls/141376
Avoid overly long paths in the title bar using the `~` prefix.
Based on feedback from !141059 there is consensus on supporting this
on Linux, that PR also supports abbreviations on other systems but
platform maintainers had concerns (see PR for details).
Apply the functionality for generic Linux/Unix systems,
the functionality for other platforms can be evaluated separately.
Follow up to #140668 that fixes the same issue when using multiple
windows & scenes. This is needed as the active tool can apply to
multiple scenes.
Ref !141260
Rename `render_bmp` to `bitmap_rgba` since BMP has an assassination
with the BMP file format, and this is an RGBA equivalent of an existing
`bitmap` variable.
This PR replaces our current custom mouse cursors (defined in
wm_cursors.cc using bitmaps and masks that we edit with a python
program) with SVG sources that are rasterized at the exact size when
needed. For Windows this would also replace the 29 platform-specific
"cur" files, although this PR does not actually remove those. For Linux
this creates the same kind of cursor as now (1bpp XBitMap) but at a
better size.
Pull Request: https://projects.blender.org/blender/blender/pulls/140990
Toggle support for brushes was added back in 4.5 with
9e1e9b0859. The intent of this feature is
to allow for easy switching between a specified brush upon using a
hotkey.
Whils this behavior works well in the case of switching between brushes,
the initial implementation didn't account for using other non-brush
tools.
To fix this issue, when activating a tool, if it doesn't handle brushes,
clear the last active brush.
Pull Request: https://projects.blender.org/blender/blender/pulls/141161
A non UTF8 title on Wayland causes disconnection from the server.
Resolve by using the path as-is unless invalid UTF8 byte sequences
are found, in that case they're replaced by `?`.
This is skipped on WIN32 & macOS since the issue only exists on Wayland.
Apply the "Zoom direction" preference to the rotation axis.
Until now, this preference was limited to translations.
Note that the X/Y swap is now applied in the accessor functions instead
of wmNDOFMotionData::tvec because swapping the X/Y axis doesn't work
well in some cases (color picker for example), and it's confusing
of axis swapping is handled in different parts of the code for
rotation & translation.
Ref !140975
Co-authored-by: Patryk-Skowronski <patryk_skowronski@3dconnexion.com>
The theme cursor size was ignored when setting custom cursors
such as the knife, only the DPI from GHOST was taken into account.
This meant cursors such as the knife would sometimes display too small.
Now when the theme-size is larger, a larger cursor will be used.
Currently the theme size is read from XCURSOR_SIZE environment variable
however it may be read from the system preferences in the future.
Also fix the software cursor sizes which incorrectly used the UI scale
preference which is ignored by cursor sizes.
This commit cleanly splits IDProperties storage for its two very different
usages:
* "User-defined" data, also known as "custom properties". Mostly exposed
in UI and as 'dictionary' in Python scripting, these are unique to each data
(each object can have its own set of custom properties).
* "System-defined" data, mainly as backend-storage for runtime RNA
structures and properties. While these are not necessarily present in the
storage, they are registered for a data type, and therefore always available
to all data of that type through RNA access.
See #123232 for rationales, designs and alternative investigated solutions.
## User-facing Changes
When using Blender, the only noticeable change is that python-defined RNA
data are not listed anymore in the Custom Properties panels (e.g. Cycles
data).
From a Python API perspective, the main changes are:
* Runtime RNA structs defined by sub-classing `PropertyGroup` and
registering them are no more accessible through the 'dict' syntax.
* They remain accessible through a dedicated 'bl_system_properties_get()`
callback, but its usages are only expected to be for testing and
debugging.
* The result of this call will be `None` by default when there has been
nothing written into it yet, unless its optional `do_create` parameter
is set to `True`.
* Some types (like `Node`, `UIList`, etc.) cannot store raw IDProperties
anymore (using the 'dict' syntax).
## Technical Details
* Adds System idprops to some data types (IDs, ViewLayer...).
* Moves some other containers (e.g operator properties, or some UI types like
UILists) to only have system-defined properties.
* For a few specific types (like `PropertyGroup`), the same storage is used,
but exposed in RNA as both user and system properties.
* Adds RNA API accessor callback to system idprops.
* Adds a function `bl_system_properties_get()`, which wraps system-defined
idprops and gives 'dict-like' access to them. Currently mainly used by some
unittests.
* System IDProps are always ignored by RNA diffing code (and therefore
liboverride processing), as their value is already exposed through RNA
properties, and should always be processed through these RNA properties.
* Modifies bpy rna binding to use these new system idprops for property
accesses, and keeps using user-defined idprops for 'dict-type' accesses.
* Handles versioning by copying 'user idprops' (existing ones) into new
'system idprops'.
### IDProperties Split
These types keep their historic IDProperty storage for user properties,
and get a new `system_id_properties` storage for system properties:
`ID`, `ViewLayers`, `Bone`, `EditBone`, `BoneCollection`, `PoseBone`, `Strip`
These types can both be extended with registrable RNA properties, and
expose Custom Properties in the UI.
### IDProperties become System Ones
These types keep a single IDProperties storage (their DNA struct does not
change), but it is now exclusively used for system-defined properties.
`OperatorProperty`, `View3DShading`, `UIList`, `AddonPreferences`,
`KeyConfigPreferences`, `GizmoProperties`, `GizmoGroupProperties`,
`Node`, `NodeSocket`, `NodeTreeInterfaceSocket`, `TimelineMarker`,
`AssetMetaData``
Since user properties were never available in the UI for them, they lose
their 'dict-like' IDProperties access in the Python API.
### Single Storage, Exposed as Both in API
These types still use a single IDProperty storage, but expose it both as
user properties and as system ones through RNA API.
* `PropertyGroup`: They need both access APIs since they are both
used for raw IDProperty groups (the 'dict-like' access), and
internally to access data of runtime-defined RNA structs.
* `IDPropertyWrapPtr`: Done mainly to follow `PropertyGroup`.
* `NodesModifier`: cannot become purely system idprops currently, as
there is no other access than the 'raw ID properties' paths to their
values. This can be changed once #132129 is finally implemented.
Pull Request: https://projects.blender.org/blender/blender/pulls/135807
This replaces API for accessing the uiLayout fixed_size,
red_alert, root_panel, search_weight and width properties
with methods, following uiLayout refactors and the
Python API naming
Pull Request: https://projects.blender.org/blender/blender/pulls/140673
When the colored titlebar decoration style was implemented in
PR #123982, both the titlebar background and foreground were exposed
to the OS backends to be used when styling the Blender window titlebar.
In practice, both backends that implement this decoration style (Win32
and macOS/Cocoa) only use the background color, and they either rely on
the OS to automatically set the text color or use the color HSV value
component to switch between the OS dark/white color.
While it was thought to still keep this value around for a potential
future backend implementation, the color settings parsed to obtain the
titlebar color (`TH_BUTBACK_TEXT_HI`, which wasn't properly suited for
this feature to begin with) has been replaced by `TH_TEXT` in #140726,
which ends up being too bright to be used as titlebar text for most
themes/use cases.
As such, this PR removes this unused titlebar decoration style setting.
Future backends that wishes the implement the colored titlebar
decoration style should either use an existing OS/DE text color or use
a set white/dark text color, similarly to what the Cocoa backend does.
Pull Request: https://projects.blender.org/blender/blender/pulls/140823
Restore expected behavior of the NDOF, especially in the context of
non-3D editors. It addresses the following issues:
- Object mode, 3D viewport:
With "Lock Horizon" off, the rotation axes will invert unexpectedly,
making the camera behave similar to a "Fly mode".
- Fly mode, 2D editors:
Changing a navigation mode to "Fly" makes no effect.
Applies to UV and Nodes editors, Camera Preview etc.
Related to #140165
This includes some minor API changes back-ported from `main`
since the PR was created for `main`.
Co-authored-by: Patryk-Skowronski <patryk_skowronski@3dconnexion.com>
Ref !140537
