| Age | Commit message (Collapse) | Author |
|---|
|
This allows the use of C++ data structures to simplify code and
improve performance.
|
|
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.
|
|
|
|
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.
|
|
Also add missing task-ID reference & remove colon after \note as it
doesn't render properly in doxygen.
|
|
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 7849b56c3c41.
|
|
Harmless but could cause file-select events to have WM_EVENT_IS_REPEAT
set which logged a warning as this is only intended for keyboard events.
|
|
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
|
|
Regression in [0] caused by checking the screen after event handling.
[0]: d4bdf2192964f786520c774d1a2ee44617302bc1
|
|
- Add logging for CLICK_DRAG event handling to debug drag events.
- Use logging API for reporting the key-map, operator and event.
This command now prints useful information for investigating
key-map and event handling issues:
blender --log "wm.handler.*" --log-level 4
|
|
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]: 4986f718482b061082936f1f6aa13929741093a2
|
|
Since the XR area does not have any region geometry, hud updates from
operators would cause invalid access when updating region sizes.
|
|
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]: a1c8543f2acd7086d412cb794b32f96794b00659
|
|
Caused by 08d8eee006f7e2a7ac05ef691bbaee230cbfbe5a.
|
|
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.
|
|
Change early drag evaluation added in
1f1dcf41d51a03150ee38f220c590f8715b11e88 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 08d8eee006f7e2a7ac05ef691bbaee230cbfbe5a 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.
|
|
This simplifies checking for event types that support press & release.
|
|
Also simplify modifier & keymodifier assignment.
|
|
|
|
|
|
No functional changes, largely restoring old logic & removing the need
for workarounds.
Reverts:
- 13b6cec039681db40e677463aa9fdff6d55896aa.
- aa71414dfca7f301e101cce3e72551e7529290ea (partially).
|
|
This feature was never exposed to users.
|
|
Partially revert aa71414dfca7f301e101cce3e72551e7529290ea
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.
|
|
Always use event.prev_click_type since this is never set on key-release,
which could still interrupt dragging (box selecting for example).
|
|
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.
|
|
Also remove event print left in by accident.
|
|
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
|
|
db4313610cab18933c1b1b1348720ea241b9d91e 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.
|
|
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.
|
|
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.
|
|
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
|
|
|
|
Use the ID.recalc flag to detect when updates after frame-change is
needed. Since comparing the last calculated frame doesn't take undo into
account (see code-comment for details).
`ID_RECALC_AUDIO_SEEK` has been renamed to `ID_RECALC_FRAME_CHANGE`
since this is not only related to audio however internally this flag is
still categorized in `NodeType::AUDIO`.
Reviewed By: sergey
Ref D13942
|
