The behavior for loading factory settings wasn't clear for users.
This commit changes the behavior:
- Loading factory settings always disables auto-save
for the current session.
- The internal setting to skip saving on exit is now exposed
in the preferences (when enabled).
- The menu item "Load Factory Settings (Temporary)" has been removed
since it's always temporary.
This way users can always reset factory settings without
having to consider the combination of options that might cause their
preferences to be overwritten at exit.
If they want to enable auto-save for the current session
this can be done from the preferences.
Cheap tip: anything that is not "Camel Case" and/or that is more than
a few words long should use `TIP_` translation, not `IFACE_` one.
Also added several missing strings (including the one reported in D5056
by Jean First (@robbott), thanks).
It could be argued this was correct behavior, since auto-save
defaults to 'on' nevertheless, auto-saving settings once
the user has disabled auto-save can lead to accidents.
Don't reset the preferences flag when resetting preferences.
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.
This new cursor is used instead of the ARROW because it was too disruptive while you are drawing.
The change affects all paint modes that are used Brushes.
See D5036 for details.
Reviewers: @brecht @billreynish @mendio
Cursor designed by: @billreynish
Respect do_time flag in on_visible_update, matching behavior of old
dependency graph and avoids unwanted animation updates.
Reviewers: brecht
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D5026
This change makes it so sound handles are created for evaluated scene,
sequencer and speakers. This allows to have properly evaluated animation
on them.
For the viewport playback sound uses regular dependency graph.
For the final render sound uses dependency graph created for render pipeline,
which now also contains sequencer and sound datablocks.
All the direct sound update calls are replaced with corresponding dependency
graph recalc tag.
For some cases like the edit mode context menu we don't currently have a fixed
title since it's dynamic. This should be improved, but we should at least still
show Call Menu if there is no menu title.
Now, the file does not have to be reloaded in all cases.
Instead, just scripts are enabled and all depsgraphs freed.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D5000
Now a small threshold is used for mouse input,
avoiding delay when gizmos are activated on drag.
Tablet input threshold remains unchanged since
it's easier to make small movements when using a tablet.
A larger threshold for non-cursor input is now used (typically keyboard)
which improves usability when the "Pie Menu on Drag" key-map preference.
Minor changes to recent gizmo click/drag logic 08dff7b40b
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 5adfc51a0f, sharing keymaps caused changing tools to
unregister gizmos and remove their keymaps.
Workaround for now by not removing the keymap.
Loading factory preferences from the preferences window and triggering a
redraw then would cause the failing assert.
We shouldn't mess with window-manager data when loading preferences
only.
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.
