Support this for completeness, as it's simpler to support click-drag
for all events types that support press/release instead of having to
document which kinds buttons support click-drag.
In practice this didn't cause a bug since assigning hot-keys was also
checking for "press" events (which NDOF_MOTION doesn't generate).
Add ISNDOF_BUTTON macro which is now used by ISHOTKEY to avoid
problems in the future.
Just use the image-buffer size and the already provided scale to
determine the size, not the button size (which would always have to
match the scaled image-buffer size or it would give unexpected results).
Since removal of tweak events 4986f71848,
box-select is activating while dragging files.
As far as I can tell this used to work because of differences
int the order tweak / click-drag events are handled.
Apply a workaround since dragging files doesn't prevent other parts
of the UI from activated (it's possible to open menus for e.g),
this is something we will likely want to limit which would resolve
this bug too.
Partially revert aa71414dfc
This attempted have the click-drag event compatible with old tweak
events, but needs to be re-thought since it caused events to be handled
in unexpected situations.
This branch was previously run when the action had been handled,
since action checks were removed it was running. This assignment
does nothing but shouldn't be kept.
Supporting two kinds of dragging is redundant, remove tweak events as
they only supported 3 mouse buttons and added complexity from using the
'value' to store directions.
Support only click-drag events (KM_CLICK_DRAG) which can be used with
any keyboard or mouse button.
Details:
- A "direction" member has been added to keymap items and events which
can be used when the event value is set to KM_CLICK_DRAG.
- Keymap items are version patched.
- Loading older key-maps are also updated.
- Currently the key-maps stored in ./release/scripts/presets/keyconfig/
still reference tweak events & need updating. For now they are updated
on load.
Note that in general this wont impact add-ons as modal operators don't
receive tweak events.
Reviewed By: brecht
Ref D14214
Clicking and dragging markers accumulates flags from multiple operators
in a way that can't be interpreted when combine.
Follow tweak behavior for cancelling click-drag events.
Replacing tweak key-map items with click-drag caused selection
in the graph/sequencer/node editors to ignore drag events
(all uses of WM_generic_select_modal).
Operators that return OPERATOR_PASS_THROUGH | OPERATOR_FINISHED
result in the event loop considering the event as being handled.
This stopped WM_CLICK_DRAG events from being generated which is not the
case for tweak events.
As click-drag is intended to be compatible with tweak events,
accept drag events when WM_HANDLER_BREAK isn't set or when
wm_action_not_handled returns true.
Mousemove events are sent to windows.
In Windows OS, almost all mousemove events are sent to the window whose
mouse cursor is over.
On MacOS, the window with mousemove events is always the active window.
It doesn't matter if the mouse cursor is inside or outside the window.
So, in order for non-active windows to also have events,
`WM_window_find_under_cursor` is called to find those windows and send
the same events.
The problem is that to find the window, `WM_window_find_under_cursor`
only has the mouse coordinates available, it doesn't differentiate
which monitor these coordinates came from.
So the mouse on one monitor may incorrectly send events to a window on
another monitor.
The solution used is to use a native API on Mac to detect the window
under the cursor.
For Windows and Linux nothing has changed.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D14197
db4313610c added support for modifier
keys to be released while dragging.
The key release events set wmEvent.prev_type which is used select the
drag threshold, causing the wrong threshold to be used.
Add wmEvent.prev_click_type which is only set when the drag begins.
Use a flag for events to avoid adding struct members every time a new
kind of tag is needed - so events remain small.
This also simplifies copying settings as flags can be copied at once
with a mask.
The UI context was only set for the operator polls, but not for the
drop-box polls. Initially I thought this wouldn't be needed since the
drop-boxes should leave up context polls to the operator, but in
practice that may not be what API users expect. Plus the tooltip for the
drop-boxes will likely have to access context anyway, so they should be
able to check it beforehand.
Now drag & tweak can have modifier keys to be released while dragging.
without this, modifier keys needs to be held which is more noticeable
for tablet input or whenever the drag threshold is set to a large value.
Resolves T89989.
Trust user count to actually delete or not the dragged ID when current
dragging is cancelled, since it may be already used by others.
NOTE: This is more a band-aid fix than anything else, cancelling drag
has a lot of other issues here (like never deleting any indirectly
linked/appended data, etc.). It needs a proper rethink in general.
Using flags makes checking multiple modifiers at once more convenient
and avoids macros/functions such as IS_EVENT_MOD & WM_event_modifier_flag
which have been removed. It also simplifies checking if modifier keys
have changed.
Drag Action was constantly resetting itself to "move".
Solve this by storing the tool settings per tool and no longer clear
gizmo properties when activating a new tool.
After using MEM_dupallocN() on the original item/binding, the
user/component path ListBase for the new item/binding needs to be
cleared and each path copied separately.
Significantly improves loading speed of preview images from disk, e.g. custom
previews loaded using `bpy.utils.previews.ImagePreviewCollection.load()`.
See D14144 for details & comparison videos.
Differential Revision: https://developer.blender.org/D14144
Reviewed by: Bastien Montagne
This adds initial support for edit mode for the experimental new curves
object. For now we can only toggle in and out of the mode, no real
interraction is possible.
This patch also adds empty menus in edit mode. Those were added mainly
to quiet warnings as the menus are programmatically added to the edit
mode based on the object type and context.
Ref T95769
Reviewed By: JacquesLucke, HooglyBoogly
Maniphest Tasks: T95769
Differential Revision: https://developer.blender.org/D14136
This adds the boilerplate code that is necessary to use the tool/brush/paint
systems in the new sculpt curves mode.
Two temporary dummy tools are part of this patch. They do nothing and
only serve to test the boilerplate. When the first actual tool is added,
those dummy tools will be removed.
Differential Revision: https://developer.blender.org/D14117
Previously, the number of action map subactions was limited to two per
action (identified by user_path0, user_path1), however for devices with
more than two user paths (e.g. Vive Tracker) it will be useful to
support a variable amount instead.
For example, a single pose action could then be used to query the
positions of all connected trackers, with each tracker having its own
subaction tracking space.
NOTE: This introduces breaking changes for the XR Python API as follows:
- XrActionMapItem: The new `user_paths` collection property
replaces the `user_path0`/`user_path1` properties.
- XrActionMapBinding: The new `component_paths` collection property
replaces the `component_path0`/`component_path1` properties.
Reviewed By: Severin
Differential Revision: https://developer.blender.org/D13949
This adds a new sculpt mode to the experimental new curves object.
Currently, this mode can only be entered and exited, nothing else.
The main initial purpose of this node will be to use it for hair grooming.
The patch also adds the `editors/curves/` directory for the new curves
object, which will be necessary for many other things as well.
I added a completely new mode (`OB_MODE_SCULPT_CURVES`), because
`OB_MODE_SCULPT` seems to be rather specific to meshes, and reusing
it doesn't seem worth the trouble. The tools/brushes used in mesh vs.
curves sculpt mode are quite distinct as well.
I had to add DNA_userdef_enums.h to make the patch compile with C++
(forward declaration of enums isn't allowed). This follows the same
pattern that we use for other enums in dna.
Differential Revision: https://developer.blender.org/D14107
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
