This should be purely an implementation change,
for end users there should be no functional difference.
The entire key configuration is in one file with ~5000 lines of code.
Mostly avoiding code duplication and preserve comments and utility
functions from the C code.
It's a bit long but for searching and editing it's also convenient to
have it all in one file.
Notes:
- Actual keymap is shared by blender / blender_legacy
and stored in `keymap_data/blender_default.py`
This only generates JSON-like data to be passed into
`keyconfig_import_from_data`, allowing other presets to load and
manipulate the default keymap.
- Each preset defines 'keyconfig_data'
which can be shared between presets.
- Some of the utility functions for generating keymap items still
need to be ported over to Python.
- Some keymap items can be made into loops (marked as TODO).
See: D3907
This is a variation of legacy dependency graph update check based on
G.is_rendering. Now it is ensured, that locked interface does not
tempter around with the dependency graph.
Previously the brush names were used which had the limit that:
- Brush names that were deleted wouldn't show up in the toolbar.
- Naming collisions between user defined brushes and existing tools
broke tool selection.
Now brushes are created as needed when tools are selected.
Note, vertex/weight paint combine tool and blend modes,
this should be split out into a separate enum.
It is a whole point of copy-on-write to make such updates safe.
If this causes an issues, we need to solve them.
Fixes T57302: Viewport (selection etc) not updated while rendering
When a .blend file is dropped into Blender a small menu opens.
In that menu the user can choose between three options: Open, Link and Append.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D3801
Looks like we need to explicitly set i18n language to default value on
some OSs... Unless that 'need to create new translated-name IDs in
versionning code for startup file' situation is really seldom.
Anyway, hopefully that will fix the crash.
This is to solve an issue where a blend file could be compressed
unbeknownst to the artist. This happened in the following situtation:
- Artist edits an uncompressed blend file.
- Some script saves a compressed blendfile to a separate location.
- When the artist saves the file (s)he is editing (File>Save, or Ctrl+S),
it was silently compressed.
Cherry pick from: cd3b313d5f
Problem was that the event was not `NULL` even though the `context` is `WM_OP_EXEC_*`.
I noticed this problem when dropping .blend files into Blender.
Instead of only executing `WM_OT_open_mainfile`, it was invoked (opening a file selector).
The `wm_operator_invoke`, which also executes operators, always invokes operators when `event != NULL`. So setting `event` to `NULL` tells `wm_operator_invoke` not to invoke but to execute the operator.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D3799
This is to solve an issue where a blend file could be compressed
unbeknownst to the artist. This happened in the following situtation:
- Artist edits an uncompressed blend file.
- Some script saves a compressed blendfile to a separate location.
- When the artist saves the file (s)he is editing (File>Save, or Ctrl+S),
it was silently compressed.
This allows gizmo groups to store properties in the tool.
This makes sense for gizmo options which only control gizmo display and
don't control operator execution.
Unlike similar kinds of properties,
this isn't accessible via the gizmo-group-type instance.
For now the it's only stored in the workspace tool as can be done for
operator properties, so each instance doesn't have different settings
which would be confusing from a user perspective and complicate access
from the top-bar.
Later we could add gizmo-group properties if needed.
