| Age | Commit message (Collapse) | Author |
|---|
|
This change ensures that operators which needs access to evaluated data
first makes sure there is a dependency graph.
Other accesses to the dependency graph made it more explicit about
whether they just need a valid dependency graph pointer or whether they
expect the graph to be already evaluated.
This replaces OPTYPE_USE_EVAL_DATA which is now removed.
Some general rules about usage of accessors:
- Drawing is expected to happen from a fully evaluated dependency graph.
There is now a function to access it, which will in the future control
that dependency graph is actually evaluated.
This check is not yet done because there are some things to be taken
care about first: for example, post-update hooks might leave scene in
a state where something is still tagged for update.
- All operators which needs to access evaluated state must use
CTX_data_ensure_evaluated_depsgraph().
This function replaces OPTYPE_USE_EVAL_DATA.
The call is generally to be done in the very beginning of the
operator, prior other logic (unless this is some comprehensive
operator which might or might not need access to an evaluated state).
This call is never to be used from a loop.
If some utility function requires evaluated state of dependency graph
the graph is to be passed as an explicit argument. This way it is
clear that no evaluation happens in a loop or something like this.
- All cases which needs to know dependency graph pointer, but which
doesn't want to actually evaluate it can use old-style function
CTX_data_depsgraph_pointer(), assuming that underlying code will
ensure dependency graph is evaluated prior to accessing it.
- The new functions are replacing OPTYPE_USE_EVAL_DATA, so now it is
explicit and local about where dependency graph is being ensured.
This commit also contains some fixes of wrong usage of evaluation
functions on original objects. Ideally should be split out, but in
reality with all the APIs being renamed is quite tricky.
Fixes T67454: Blender crash on rapid undo and select
Speculation here is that sometimes undo and selection operators are
sometimes handled in the same event loop iteration, which leaves
non-evaluated dependency graph.
Fixes T67973: Crash on Fix Deforms operator
Fixes T67902: Crash when undo a loop cut
Reviewers: brecht
Reviewed By: brecht
Subscribers: lichtwerk
Maniphest Tasks: T67454
Differential Revision: https://developer.blender.org/D5343
|
|
|
|
Thanks to Sergey and Clément for helping to track this down.
|
|
|
|
|
|
|
|
Gizmo group types now store a user count so they aren't unlinked
while other tools are using them.
The tool system now works with multiple windows.
|
|
Introduced in recent commit c93af8529dfec
|
|
|
|
Also comment corrections.
|
|
Found while investigating T65963.
|
|
Clear gizmo highlight when the cursor leaves the region.
|
|
Pre-calculates values needed for unprojecting to avoid
a matrix invert and extracting projection matrix dimensions for
every call to GPU_matrix_unproject.
Use for gizmo selection drawing.
|
|
Improvements to behavior for gizmo tool-tips.
- 2D gizmos no longer cancel tool-tips on cursor motion
(matching the behavior of UI widgets).
- 3D gizmos still close on motion since 3D gizmos may have a large
on-screen area which would cause them to stay visible even after the
cursor has been moved a large distance. The motion threshold is used
so they don't close on unintended cursor motion.
- Changing highlighted gizmo now cancels the tool-tip & resets the timer.
|
|
The legacy keymap now activates on press.
|
|
|
|
|
|
|
|
Allows gizmos clicks to fall through for gizmos which only drag,
currently unused.
|
|
Existing functions were written to match the setup_keymap callback.
Add versions that can be called with the window manager for convenience.
|
|
|
|
Operator flags to wrap on a single axis.
D4865 by @Gvgeo with updates.
Resolves T64585
|
|
Don't use plural because single/multiple isn't relevant
for keymap definitions and reads badly for specific gizmo types
that only use a single gizmo.
|
|
An operator can only have one modal keymap,
there is no use in defining multiple.
|
|
Check the current events modifiers against the gizmo keymap,
only highlighting when keymap items match.
Needed to resolve T63996
|
|
Minor changes to recent gizmo click/drag logic 08dff7b40bc6a
Changing the gizmos highlighted part in the invoke_prepare
callback is too error prone since it needs to run
before it's known which operator will execute.
Add back 'drag_part', since it simplifies click-drag use.
While this isn't essential with custom keymaps per gizmo
it avoids having to define a keymap in the case a drag
event needs a different action.
|
|
Remove click-drag support for tweak gizmo,
rely on keymap events instead.
This is needed for some gizmos to use modifiers keys
without having all gizmos use all modifier keys (see: T63996).
|
|
It was possible to use a drag event for a gizmo
that dragged away from the gizmo, changing the active gizmo.
Now use gizmo located at the location that was clicked on.
|
|
|
|
Caused by 5adfc51a0fc7f, sharing keymaps caused changing tools to
unregister gizmos and remove their keymaps.
Workaround for now by not removing the keymap.
|
|
While support for gizmo specific keymaps remains, this should only
be used if a gizmo-group is doing something that requires one.
There was also a hidden limitation that meant only the last registered
tweak keymap would ever be used.
For now leave this using the generic keymap since all
tweak modal keymaps were using the same template anyway.
|
|
While internally these are separate gizmos,
there is no reason to have a keymaps for each.
Also prefix the gizmo with "3D View"
since there are other kinds of transform gizmos.
|
|
|
|
Avoids an allocation per gizmo & simplifies limiting the lookup
past the first intersecting 2D gizmo found.
|
|
This also makes `IDP_CopyProperty` the "opposite"
of `IDP_FreeProperty`, which is what I'd expect.
Two refactoring steps:
* rename IDP_FreeProperty to IDP_FreePropertyContent
* new IDP_FreeProperty function that actually frees the property
Reviewers: brecht
Differential Revision: https://developer.blender.org/D4872
|
|
This allows some gizmos priority over others even when they're behind.
|
|
|
|
|
|
|
|
Apply clang format as proposed in T53211.
For details on usage and instructions for migrating branches
without conflicts, see:
https://wiki.blender.org/wiki/Tools/ClangFormat
|
|
|
|
|
|
This was using hard coded values of 2-3px.
Move both drag and motion thresholds to defines.
|
|
Convention was not to but after discussion on 918941483f7e we agree its
best to change the convention.
Names now mostly follow RNA.
Some exceptions:
- Use 'nodetrees' instead of 'nodegroups'
since the struct is called NodeTree.
- Use 'gpencils' instead of 'grease_pencil'
since 'gpencil' is a common abbreviation in the C code.
Other exceptions:
- Leave 'wm' as it's a list of one.
- Leave 'ipo' as is for versioning.
|
|
Re-create gizmos when changing theme colors, since
theme colors don't change often this allows gizmos to setup their
colors on initialization.
|
|
Makes it more clear it's the header/start of the struct.
|
|
|
|
|
|
While \file doesn't need an argument, it can't have another doxy
command after it.
|
|
Tools were relying on gizmos drawing to initialize their gizmos,
now tool gizmos are initialized immediately.
|
