As Wayland doesn't support moving the cursor, draw a cross-hair cursor
at the location used by Blender.
Without this, the cursor was locked at the location where grab started,
making some actions unusable since the cursor location was invisible.
Resolves T77311.
NOTE: this patch originated in T98015 which was split into multiple
reports. While it could be split into multiple patches these are very
much related so keeping as one for now
This patch fixes the following issues:
[1] autokeying transforms in preview only creates keyframes if there is
an FCurve already
[2] autokeying transforms in preview only creates keyframes for
rotation/scale if rotating/scaling around cursor (should keyframe
position as well)
[3] autokeying transforms in preview does not work during animation
playback
For [1], a param was added to `ED_autokeyframe_property` which can tweak
its default behavior of only creating keyframes on already keyed
properties (which was fine because this is mostly called from buttons
where this behavior is desired). Callers such as gizmos (or the VSE in
our case) can use this additional param so that keyframes are also
created on "not-yet-keyframed" properties.
For [2], the pivot is checked and position properties also keyed if
necessary (which is also consistent with the way objects are keyed in
the 3DView)
For [3], `animrecord_check_state` was changed to be able to work on
scenes as well and the transform system in the VSE preview was made
aware of the screen's `animtimer`.
NOTE: there are still things to be improved for keyframing in the VSE,
the most obvious is probably a `keyframe_insert` operator (with
keyingsets)
Fixes T98429, T98430, T98431
Maniphest Tasks: T98015, T98431, T98430, T98429
Differential Revision: https://developer.blender.org/D15047
The transformation snapping code contains a bunch of `#define`s, some ambiguously or incorrectly named attributes. This patch contains refactored code to improve this. This patch does (should) not change functionality of snapping.
Clarified ambiguously / incorrectly named attributes.
- "Target" is used to refer to the part of the source that is to be snapped (Active, Median, Center, Closest), but several other areas of Blender use the term "target" to refer to the thing being snapped to and "source" to refer to the thing getting snapped. Moreover, the implications of the previous terms do not match the descriptions. For example: `SCE_SNAP_TARGET_CENTER` does not snap the grabbed geometry to the center of the target, but instead "Snap transforamtion center onto target".
- "Select" refers to the condition for an object to be a possible target for snapping.
- `SCE_SNAP_MODE_FACE` is renamed to `SCE_SNAP_MODE_FACE_RAYCAST` to better describe its affect and to make way for other face snapping methods (ex: nearest).
Refactored related `#define` into `enum`s. In particular, constants relating to...
- `ToolSettings.snap_flag` are now in `enum eSnapFlag`
- `ToolSettings.snap_mode` are now in `enum eSnapMode`
- `ToolSettings.snap_source` (was `snap_target`) are now in `enum eSnapSourceSelect`
- `ToolSettings.snap_flag` (`SCE_SNAP_NO_SELF`) and `TransSnap.target_select` are now in `enum eSnapTargetSelect`
As the terms became more consistent and the constants were packed together into meaningful enumerations, some of the attribute names seemed ambiguous. For example, it is unclear whether `SnapObjectParams.snap_select` referred to the target or the source. This patch also adds a small amount of clarity.
This patch also swaps out generic types (ex: `char`, `short`, `ushort`) and unclear hard coded numbers (ex: `0`) used with snap-related enumerations with the actual `enum`s and values.
Note: I did leave myself some comments to follow-up with further refactoring. Specifically, using "target" and "source" consistently will mean the Python API will need to change (ex: `ToolSettings.snap_target` is not `ToolSettings.snap_source`). If the API is going to change, it would be good to make sure that the used terms are descriptive enough. For example, `bpy.ops.transform.translate` uses a `snap` argument to determine if snapping should be enabled while transforming. Perhaps `use_snap` might be an improvement that's more consistent with other conventions.
This patch is (mostly) a subset of D14591, as suggested by @mano-wii.
Task T69342 proposes to separate the `Absolute Grid Snap` option out from `Increment` snapping method into its own method. Also, there might be reason to create additional snapping methods or options. (Indeed, D14591 heads in this direction). This patch can work along with these suggestions, as this patch is trying to clarify the snapping code and to prompt more work in this area.
Reviewed By: mano-wii
Differential Revision: https://developer.blender.org/D15037
When interacting with translate/rotate/scale gizmo, show the gizmo while
it's in use. There are some exceptions to this, as showing all scale
gizmos while scaling causes the gizmos to become large & distracting so
in this case only the gizmo being dragged is shown.
Resolves T63743.
Some operators OR'ed the existing flags in a way that made it seem
the value might already have some values set.
Replace this with assignment as no flags are set and the convention
with almost all operators is to write the value directly.
These changes make the curves sculpt mode keymap consistent
with other modes. They now show up in the keymap, for potential
editing of tool shortcuts, etc. I don't fully understand this system,
but at least these changes should make it consistent.
Differential Revision: https://developer.blender.org/D15112
Add `bpy.app.is_job_running(job_type)` as high-level indicator. Job
types currently exposed are `WM_JOB_TYPE_RENDER`,
`WM_JOB_TYPE_RENDER_PREVIEW`, and `WM_JOB_TYPE_OBJECT_BAKE`, as strings
with the `WM_JOB_TYPE_` prefix removed. The functions can be polled by
Python code to determine whether such background work is still ongoing
or not.
Furthermore, new app handles are added for
`object_bake_{pre,complete,canceled}`, which are called respectively
before an object baking job starts, completes sucessfully, and stops due
to a cancellation.
Motivation: There are various cases where Python can trigger the
execution of a background job, without getting notification that that
background job is done. As a result, it's hard to do things like
cleanups, or auto-quitting Blender after the work is done.
The approach in this commit can easily be extended with other job types,
when the need arises. The rendering of asset previews is one that's
likely to be added sooner than later, as there have already been
requests about this.
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D14587
The tweak tool was toggling node selection twice, as the selection
key-map is already accounted for in the node key-map there is no need
to duplicate the actions in the tweak tool.
This could happen when switching between custom action sets that both
had controller pose actions. Problem was that controller data is
cleared when changing action sets, and this clearing was done when
handling WM events, which always occurs after XR controller data is
updated from GHOST.
Now, instead of activating the action set immediately, delay activation
until just before the next XR actions sync.
After removing the default 'Home' shortcut for "Frame All", a NDOF (3D
Mouse) default shortcut was still available for the operator. The event
filtering introduced in 4357fb63db was missing the NDOF filtering
logic. So while the context menu correctly found the NDOF keymap item,
its actual shortcut change/removal code incorrectly filtered out the
NDOF keymap items and thus failed to find the item.
Currently strings are used for cases where a list of identifiers would
be useful to show.
Add support for string properties to reference a callback to populate
candidates to show when editing a string. The user isn't prevented from
typing in text not found in this list, it's just useful as a reference.
Support for expanding the following strings has been added:
- Operator, menu & panel identifiers in the keymap editor.
- WM operators that reference data-paths expand using the
Python-consoles auto-complete functionality.
- Names of keying sets for insert/delete keyframe operators.
Details:
- `bpy.props.StringProperty` takes an option `search` callback.
- A new string callback has been added, set via
`RNA_def_property_string_search_func` or
`RNA_def_property_string_search_func_runtime`.
- Addresses usability issue highlighted by T89560,
where setting keying set identifiers as strings isn't practical.
- Showing additional right-aligned text in the search results is
supported but disabled by default as the text is too cramped in most
string search popups where the feature would make sense. It could be
enabled as part of other layout tweaks.
Reviewed By: brecht
Ref D14986
The wm_gesture_tag_redraw function was only called on mouse move, so the
flip state preview was not updating just by pressing the F key.
Reviewed By: Severin
Maniphest Tasks: T83519
Differential Revision: https://developer.blender.org/D9779
Dropping would pass the name of the ID to drop to the properties of the
drop operator. This would then lookup the ID by name. With linking
and/or library overrides, multiple IDs of the same name and type may
exist, which is why the session UUID should be used instead. All
operators used for dropping support this now and the drop code passes
the session UUID instead of the name.
Also see 917c096be6 and 8f79fa9c67.
Some drop operators were already using the session UUIDs. This converts
the remaining ones. The "name" property is kept working as before, since
some scripts use this.
Side-effect: The "Name" property won't show up in the Adjust Last
Operation anymore, which was the case for some of these operators, and
its value won't be remembered over multiple executions of the operator.
Both were not at all useful from what I can tell, and I doubt this was
done intentionally.
There are now some generalized helpers for passing IDs from drag & drop
to operators via operator properties, mostly introduced in 917c096be6
and 8f79fa9c67. These can be used in a bunch of places to reduce
duplicated code and explicitly share a common solution.
Side-effect: The "Name" property won't show up in the Adjust Last
Operation anymore, and its value won't be remembered over multiple
executions of the operator. Both were not at all useful from what I can
tell, and I doubt this was done intentionally.
Continuation of 8f79fa9c67 and 917c096be6. The ID's session UUID is
now always priotitized over its name to lookup the ID from drop-box or
operator properties. bc3dbf109c shows what happens if the name happens
to be set for whatever reason and the session UUID isn't prioritized.
More and more of the drop operations are being switched to use the ID's
session UUID rather than the name, but the cleanup after a drop operator
was cancelled assumed they would set the name. They will now first
attempt to use the session UUID and fallback to the name if needed.
When saving from the menu the region was not set,
causing the last region in `area->regionbase` to be used
as the region was assigned before comparison.
917c096be6 applied to objects only, this also applies the same fix for
the general 3D View drop operations, e.g. used for dragging materials,
images, worlds, etc.
This is needed to fix T95706, but apparently something else is still
going on. Needs further investigation.
Steps to reproduce were:
- Open Clip Editor
- Call "Open Clip" (e.g. Alt+O)
- Select video file
The file wouldn't be loaded into the Clip Editor.
Caused by 7849b56c3c.
This is part of a fix for T88570, where the file selector would crash
when activated multiple times.
Calling save multiple times would free the operator, leaving a dangling
pointer which was used when panels were visible that accessed the
"active_operator".
Reviewed By: Severin
Ref D14905
Existing code to replace the file operation was failing when done from
the window for the file operation itself.
Basically, this patch does two things:
- Implement a well defined window context to use as the "owner" or
"root" of the File Browser. This will be used for managing the File
Browser and to execute the file operation, even after the File Browser
was closed.
- Ensure the context is valid when dealing with file File Browser event
handlers.
Previously the window context just wasn't well defined and just happened
to work well enough in most cases. Addressing this may unveil further
issues, see T88570#1355740.
Differential Revision: https://developer.blender.org/D13441
Reviewed by: Campbell Barton
- In some cases it avoids using strlen on the result.
- Use ATTR_NONNULL for all arguments.
- Remove NULL pointer check for WM_operator_bl_idname src argument.
- Rename from/to to src/dst.
Refactoring event click-drag detection broke click detection for
simulated events. Resolve this by sharing logic for update previous
values in `wmWindow.eventstate` for regular event handling
(no functional changes for non-simulated events). Failure to detect
clicks for simulated events broke the undo test
`test_undo.view3d_multi_mode_select` in `../lib/tests/ui_simulate/run.py`.
All undo tests now pass.
When saving from the menu the region was not set,
causing the last region in `area->regionbase` to be used
as the region was assigned before comparison.
Steps to reproduce were:
- Open Clip Editor
- Call "Open Clip" (e.g. Alt+O)
- Select video file
The file wouldn't be loaded into the Clip Editor.
Caused by 7849b56c3c.
Manually revert commit [0] as it caused problems macOS (reported T96435).
- Includes fixes from [1] & [2].
- T98037 TODO has been created to keep track of this feature.
Thanks to @jbakker & @sergey for investigating this issue as I wasn't
able to reproduce the bug.
[0]: 0cb5eae9d0
[1]: cb986446e2
[2]: cc8fe1a1cb
This is part of a fix for T88570, where the file selector would crash
when activated multiple times.
Calling save multiple times would free the operator, leaving a dangling
pointer which was used when panels were visible that accessed the
"active_operator".
Reviewed By: Severin
Ref D14905
The acquire locking of the draw manager introduced other issues.
The current implementation was a hacky solution as we know that the
final solution is something totally different {T98016}.
Related issues:
* {T97988}
* {T97600}
The acquire locking of the draw manager introduced other issues.
The current implementation was a hacky solution as we know that the
final solution is something totally different {T98016}.
Related issues:
* {T97988}
* {T97600}
Existing code to replace the file operation was failing when done from
the window for the file operation itself.
Basically, this patch does two things:
- Implement a well defined window context to use as the "owner" or
"root" of the File Browser. This will be used for managing the File
Browser and to execute the file operation, even after the File Browser
was closed.
- Ensure the context is valid when dealing with file File Browser event
handlers.
Previously the window context just wasn't well defined and just happened
to work well enough in most cases. Addressing this may unveil further
issues, see T88570#1355740.
Differential Revision: https://developer.blender.org/D13441
Reviewed by: Campbell Barton
This is because some drivers / GPU actually still do double buffer swapping
but others don't. Adding this do ensure the background color of the first
redraw.
Note that this fix was not tested on the problematic hardware and might not
solve the issue.
The use-case is to allow an event handler (in C or a plugin) to
distinguish which hand produced the XR event.
The alternative is to register separate actions for each hand (e.g.
"trigger_left" and "trigger_right"), and duplicate the device bindings
(Oculus, HTC Vive, etc) for each action. Other than the problem of code
duplication, this isn't conceptually efficient since "trigger_left" and
"trigger_right" both represent the same event "trigger", and the
identity of the hand that produced that event is just a property of
that event.
Adds two string fields to the XrEventData called user_path and
user_path_other. The user_path_other field will be populated if the
event is a bimanual one (i.e. two-handed). This follows the pattern
used by the rest of the XrEventData struct for bimanual events (e.g.
state, state_other).
Reviewed By: muxed-reality
