Regression in [0] which removed a special check when tweak events ended.
Add a similar check for drag events that runs drag is disabled in the
main event handling loop.
[0]: 4986f71848
When converting ghost keys to Blender's event system:
- All keys that aren't part of the GHOST_TKey enum map to EVENT_NONE
(ignored), note that it's an internal error if the value of key isn't
a known value.
- Modify the switch statement so any missing members of GHOST_TKey
warn at compile time (GCC & Clang only).
- GHOST_kKeyUnknown maps to EVT_UNKNOWNKEY.
We could ignore this key, changing can be evaluated separately.
Avoid adding events with their type set to EVENT_NONE as these
can't be categorized usefully (keyboard/mouse/NDOF ... etc),
and add an extra case that needs to be accounted for.
Adding these events seems to be an unintentional change from [0],
these keys used to be ignored in 2.4x.
[0]: a1c8543f2a
Adding WITH_METAL option to CMAKE to guard compilation for macOS only. Implemented stub METALBackend to mirror GPUBackend interface and added capabilities initialisation, along with API initialisation paths.
Global rendering coordination commands added to backend with GPU_render_begin and GPU_render_end() commands globally wrapping GPU work. This is required for Metal to ensure temporary resources are generated within an NSAutoReleasePool and freed accordingly.
Authored by Apple: Michael Parkin-White, Vil Harvey, Marco Giordano, Michael Jones, Morteza Mostajabodaveh, Jason Fielder
Ref T96261
Reviewed By: fclem
Maniphest Tasks: T96261
Differential Revision: https://developer.blender.org/D14293
Also fixes missing code to read/write/free/copy color management settings
in various places. This can't be set through the UI currently, but still
should be handled consistently.
- Use set-style printing of modifier flags instead of booleans.
- Include event.flag.
- Print on a single line (so output can be more easily filtered).
In some cases value of cursor motion events was set from the last event
written to the wmWindow.eventstate. Avoid potential errors by ensuring
cursor motion events always have their value set to KM_NOTHING.
Needed so mapping selection to click doesn't pass the click event
through to setting the 3D cursor for e.g.
While this doesn't happen with the default key-map, setting selection
to LMB-click would set the 3D cursor as well (when the selection
fell through to nothing).
Currently this isn't used in the key-map, it will eventually
allow the 3D viewports tweak tool to match the behavior of other
editors that support tweaking a selection without first de-selecting
all other elements.
So far it was needed to declare a new RNA struct to `RNA_access.h` manually.
Since 9b298cf3db we generate a `RNA_prototypes.h` for RNA property
declarations. Now this also includes the RNA struct declarations, so they don't
have to be added manually anymore.
Differential Revision: https://developer.blender.org/D13862
Reviewed by: brecht, campbellbarton
Change early drag evaluation added in
1f1dcf41d5 to only apply to drag events
from mouse buttons. Otherwise pressing two keyboard keys at one would
create a drag event for the first pressed key. While this didn't cause
any bugs as far as I know, this behavior makes most sense for drags
that come from cursor input.
Only set press events in the windows eventstate, not the current event
since it's not useful for these to be set current events press values.
This makes it possible for a press event to access values for the
previous press.
Activating a gizmo used the windows eventstate which may have values
newer than the event used to activate the gizmo.
This meant transforms check for the key that activated transform
could be incorrect.
Support passing an event when calling operators to avoid this problem.
When dragging with a large threshold (using a tablet for example),
it's possible to press another key before the drag threshold is reached.
So tweaking then pressing X would show the delete popup instead of
transforming along the X-axis.
Now key presses while dragging cause the drag event to be evaluated
before the key press.
Note that to properly base the mouse-move event on the previous
state the last handled event is now stored in the window.
Without this the inserted mouse-move event may contain invalid values
from the next event (it's modifier state or other `prev_*` values).
Requested by @JulienKaspar.
Regression in 08d8eee006 caused
emulate-middle mouse to work once, clearing the modifier key.
Now the modifier key from emulated mouse events is never stored
in the windows event-state.
At the time of naming these members only some event types generated
click events so it made some sense to differentiate a click.
Now all buttons support click & drag it's more logical to use the
prefix "prev_press_" as any press event will set these values.
Also update doc-strings.
This avoids transform jumping which is a problem when tweaking values a
small amount. A fix for T40549 was made box-select used the location
when the key was pressed.
While it's important for box-select or any operator where it's expected
the drag-start location is used, this is only needed in some cases.
Since the event stores the click location and the current location,
no longer overwrite the events real location. Operators that depend on
using the drag-start can use this location if they need.
In some cases the region relative cursor location (Event.mval) now needs
to be calculated based on the click location.
- Added `WM_event_drag_start_mval` for convenient access to the region
relative drag-start location (for drag events).
- Added `WM_event_drag_start_xy` for window relative coordinates.
- Added Python property Event.mouse_prev_click_x/y
Resolves T93599.
Reviewed By: Severin
Ref D14213
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.
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.
