We have been chatting in the Animation&Rigging module meeting that the collection hotkeys (1, 2, 3 etc.) in Pose Mode are unwanted and could be replaced with something more useful.
This patch only removes the hotkeys, we can later decide what should be in their place.
Pull Request: https://projects.blender.org/blender/blender/pulls/105120
Since the change in #106113 the Slider menu which was called with the D hotkey was no longer in any menu.
This made it really hard to discover.
Since there is now more than 1 menu popup, it needs more than 1 hotkey.
The idea is that the ALT key is used in combination with keys that are easy to reach with the left hand.
Right now it is ALT+S and ALT+D but if needed in the future it can be extended to f, w and e
Pull Request: https://projects.blender.org/blender/blender/pulls/107866
There is no reason to use case-sensitive path lookups on MS-Windows.
Also replace BLI_str_endswith with BLI_path_basename since ends-with
checks don't ensure a preceding path separator.
There are other events besides `MOUSEMOVE` that's passed in during modal
handling, causes the `tgpi->mvalo` variable to be overwritten without
moving the stroke in the first place, this results in inaccurate offsets
during mouse/pen grabbing in primitive gizmo `IN_MOVE` mode. Now fixed.
Also fixed the operator hint to include the grab functionality.
Pull Request: https://projects.blender.org/blender/blender/pulls/108172
fc854fc252 caused the precision modification to be removed after
navigation was complete.
The ideal is when starting navigation.
This is because the precision button can be released during navigation,
thus confirming the precision change.
In order to execute the navigation of type "VIEW3D_OT_move," the user
is required to press both the `Shift` and `MMB` keys.
However, pressing `Shift` also activates the precision modifier for the
transform.
Consequently, while the `MMB` is unpressed, the transform operation
unintentionally remains in precision mode, altering the mouse position.
To address this issue, the solution was to eliminate the precision
changes immediately after the navigation is initiated.
Unfortunately, we have no way of knowing whether the user actually
unintentionally enabled precision, so this solution serves as a
workaround. Ideally, keymap conflicts should be avoided.
The runtime backup/restore logic was slightly wrong: it is possible that
an object requires light linking runtime but does not need light linking
itself. This is typical configuration for the receivers/blockers.
Modified the logic so that the evaluated object light linking is allocated
if there was a runtime field needed.
This required to make it so light linking evaluation takes care of feeing
the light_linking if it is empty. The downside of this approach is a
redundant allocation from the object backup when removing light linking
collection from emitter. But this is not a typical evaluation flow, and
the more typical flows are cheap with this approach.
Pull Request: https://projects.blender.org/blender/blender/pulls/108261
Regression in [0]. The only configuration that has changed is RMB select
with "Right Mouse Select" set to "Select & Tweak" (the default)
which now behaves as if [0] was reverted without reintroducing #99963.
[0]: 64dbfe714b
The original names were `...update_position()`, but no update in
position is performed in these functions, rather, the entries in
`LightSample` are updated. Also make clear that the functions are used
by MNEE.
Extract vendor, driver and device information from the physical device
properties.
Note that driver version is implementation dependent and might fail as
it is unclear which driver is being used. An open source driver could
store the driver version in a different way than a closed source driver.
But as it is not clear which driver version is being used it might
extract the incorrect version.
To solve this issue we check if the extracted version makes sense
depending on the version schema of the driver and if they don't match we
use another approach.
Pull Request: https://projects.blender.org/blender/blender/pulls/107872
The issue was that `is_rendering` was used as a proxy to check
whether the interface is locked. Locking the node editor during rendering
is not necessary, but it currently is necessary while baking, because
baking changes original data from a different thread.
The solution is to use the already existing mechanism to tell Blender
which regions should be locked when the interface is locked.
