This matches behavior on macOS as well as the property description.
On Wayland, smooth scrolling doesn't use the touchpad API,
so disabling multi-touch gestures doesn't change the behavior as it
does on macOS.
Resolve by converting vertical touch scrolling to mouse-wheel events.
This reverts commit af88ff04848b1ff299514514fb18ecf401553bb4.
That commit broke scrolling (at least in some cases).
Reverting the commit resolves#120587
The callback to set the relative direction wasn't running because
it required GHOST to request version 9 of the wl_seat_interface.
Natural touchpad events now work for KDE 6 and recent versions
of WLROOTS based compositors, GNOME 46 is uses wl_seat_interface
version 8 which still wont work.
MoltenVK original intent was to let developers work on a mac system developing
for the vulkan eco-system. MoltenVK doesn't support all the features that we
require and would require additional workarounds to be actually supported.
It is not expected that we will release Blender with MoltenVK for this reason.
But it still has value for shader developers to validate shaders on metal and
vulkan on a single platform.
![image](/attachments/9a4a9904-a5f6-4922-896d-744dfb78244c)
Pull Request: https://projects.blender.org/blender/blender/pulls/117940
We call UpdateWindow very early in our window creation, before we get
an openGl surface and before our message queue is ready. This results
in WM_ACTIVATE, WM_SIZE, WM_MOVE, and WM_PAINT messages sent to us
at a time when GetMessageTime() returns zero. This makes our event
message times have a gap between the fourth and fifth messages, equal
to the time since system start. There is no downside to not calling
this at this time.
Pull Request: https://projects.blender.org/blender/blender/pulls/117965
While an empty string resolves to the default theme, it's not following
the API specification for wl_cursor_theme_load as it's written.
Checking on wayland internals this looks only to add an unnecessary
theme lookup on an empty string which falls back to the default.
Noticed when investigating #105895 although it seems unlikely
that this chagne would resolve the issue.
Disable fix from [0] unless LIBDECOR is used.
This caused:
- KDE 6.0.2 to fail to start full-screen.
- RIVERWM to show a blank preferences.
- HYPRLAND to assert with a negative window height
when starting full-screen.
Also replace flush & dispatch with a round-trip which fixes an error
on GNOME with non maximized/full-screen windows not showing any contents
on startup until a redraw was triggered.
[0]: 7371b11bb5a5eed0205fba2c8400546073a628d6
Resolve a glitch where the window contents didn't fit the window
on startup under GNOME. This also avoids flickering whenever the
window manager changed the window size from the requested size.
See code-comments for details.
Adds copy and paste images functionality to and from the image editor
in Linux/Wayland clipboard.
Currently the only format supported is PNG.
Ref: !119117
Exact an exact match with Clang broke building when the compiler ID
was "AppleClang", reverting parts of [0].
[0]: 6549019ae19cecbea524782054dca0e99cb833b8
* Only works on machines with a Qualcomm Snapdragon 8cx Gen3 or above.
Older generation devices are not and will not be supported due to
some driver issues
* Requires VS2022 for building.
* Uses new MSVC preprocessor for sse2neon compatibility.
* SIMD is not enabled, waiting on conversion of blenlib to C++.
Ref #119126
Pull Request: https://projects.blender.org/blender/blender/pulls/117036
New windows on GNOME with LIBDECOR windowing would sometimes have an
unusable title-bar with the whole title-bar acting as the edge-resize.
Would happen predictably when opening large windows which the window
manager would resize to fit the display.
The cause of this was Blender receiving a window configure event
without a window size for new windows. This configure event
would be ignored, causing the title bar not to work properly.
This is a regression from [0] which removed logic to calculate the
window size from the arguments passed to GHOST for window creation.
This wasn't correct either as the it could temporarily set the
window size before the requested size configuration was received.
Resolve the problem by queuing configuration requests,
handling them then the requested window size is known.
[0]: 1455315111ae769d101413fe600662484ff46d62
Register the last held key when activating a window
(not only modifiers keys) under Wayland.
This resolves a bug where holding the D-key and clicking on a window
wouldn't activate grease pencil drawing.
On the MacOS platform, use openHandCursor for GHOST_kStandardCursorMove
not pointingHandCursor. This cursor is meant to indicate an item that
you can move or adjust. The pointingHandCursor is meant for links to
documents, web pages, etc.
Pull Request: https://projects.blender.org/blender/blender/pulls/118423
My misreading of the Microsoft BITMAPV5HEADER specification causes a
shift of three pixels when transferring between applications using this
format. This does not occur when moving within or between Blender
instances. This PR just removes the incorrect 12-byte offset. Note
that many applications prefer PNG transfers over DibV5 so testing this
might be non-obvious.
Pull Request: https://projects.blender.org/blender/blender/pulls/118417
The size of the string in bytes happened to match the the pointer size
on 64bit systems, nevertheless the logic was wrong would would fail on
32bit systems. Also use a character to search the string instead of a
single character string.
This isn't necessary and has been removed from macOS & X11,
Wayland never did this.
Besides removing the offset GetTickCount() has been replaced by
GetTickCount64 to prevent 32bit rollover when high resolution timers
aren't supported.
Ref !117618