Left-click select broke that behavior, since it puts both action and
select buttons on the same physical mouse button...
To support this behavior again, we have to split selection process in
two steps, hence make it modal... While I remain rather skeptical about
that global design decision, and complexity it adds to many UI/UX areas,
this solution ends up being OK-ish I think.
Thanks to @brecht for some final tweaks on the patch.
- Fix 'ddisable' typo
- Use clearer names for the operators in the Collections context menu
Instead of Set Exclude / Clear Exclude, we now use Enable in View Layer / Disable from View Layer
On Windows 10 with a post Februari 2019 Intel driver, the box selection
is not working. It only detects the object centers, but not the drawn
triangles of the basic engine.
Reviewed By: fclem
Maniphest Tasks: T62947
Differential Revision: https://developer.blender.org/D4857
The complexity in this patch comes from the fact
that the current operator system does not support
multi-step user interactions well.
More specifically, for this to work, we need to show
a confirm dialog and a file browser afterwards.
We decided that it is easier to keep everything in
a single operator, instead of creating separate
operators that invoke each other.
So, now the `WM_OT_open_mainfile` operator invokes
itself in different states. It implements a simple
finite state machine to manage the states.
The dialog itself is expected to be improved in
a future commit. See D4829 for more details.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D4829
While shapekeys RNA path handling does support keyblocks (ShapeKeys)
with an `id_data` wrongly set to the geometry instead of the shapkey,
this is really not something to promote. ideally it should be removed at
some point. At least, let's not generate such RNA pointer if we can
avoid it.
Here it was breaking proper showing of animated shapekeys in the UI,
since this expects animated datablocks to have their own animation data
(and 'rooting' keyblocks to their mesh instead of their shapekey ended
up defining their animation in the mesh, not in the shapekey).
New option to disable the follow drawing path. Before it had only a switch property, now there is a list of options.
Modes:
Path: Follows drawing stroke and rotate with object.
Object: Only follows object rotation.
None: Don't rotate.
The owning ID reference of RNA pointers is supposed to point at the
ID container that owns the object, but for PoseBone.bone it wasn't
updated to point at the Armature data ID instead of Armature Object.
This caused issues, like pose_bone.bone.driver_add() adding the
driver to the Armature Object animation data, which violates the
intended design of the animation data structures.
Since RNA code generally assumes that all pointers that don't
refer directly to an ID remain within the current ID, a custom
getter is required to fix this.
This is a big change that cleanup a lot of confusing code.
- The instancing/batching data buffer distribution in draw_instance_data.c.
- The selection & drawing code in draw_manager_exec.c
- Prety much every non-meshes object drawing (object_mode.c).
Most of the changes are just renaming but there still a chance a typo might
have sneek through.
The Batching/Instancing Shading groups are replace by DRWCallBuffers. This
is cleaner and conceptually more in line with what a DRWShadingGroup should
be.
There is still some little confusion in draw_common.c where some function
takes shgroup as input and some don't.
This is in order to have VAO handled by thoses batches instead of using a
common VAO. Even if the VAO has no importance in these case using a batch
will help when transitioning to Vulkan.
Tagging dirty was failing for UI scale, line width, hinting & others.
Checking for an update function means all update functions
need to tag preferences as dirty.
Since this check was added to prevent the active section marking the
preferences as dirty, only exclude this property.
