(Part 1 was 00963afc14978b)
Does the following changes visible to users:
* Use panels and sub-panels for more structured & logical grouping
* Re-organized options more logically than before (see images in D4148)
* Use flow layout (single column by default).
* New layout uses horizontal margin if there's enough space.
* Change size of Preferences window to suit new layout.
* Move keymap related options from "Input" into own section.
* Own, left-bottom aligned region for Save Preferences button.
* Adjustments of names, tooltips & icons.
* Move buttons from header into the main region (except editor switch).
* Hide Preferences header when opened in temporary window.
* Use full area width for header.
* Don't use slider but regular number widget for UI scale.
* Gray out animation player path option if player isn't "Custom"
Internal changes:
* Rearrange RNA properties to match changed UI structure.
* Introduces new "EXECUTE" region type, see reasoning in D3982.
* Changes to panel layout and AZone code for dynamic panel region.
* Bumps subversion and does versioning for new regions.
RNA changes are documented in the release notes:
https://wiki.blender.org/wiki/Reference/Release_Notes/2.80/Python_API/Preferences_API
Design & implementation mostly done by @billreynish and myself.
I recommend checking out the screenshots posted by William:
https://developer.blender.org/D4148#93787
Reviewed By: brecht
Maniphest Tasks: T54115
Differential Revision: https://developer.blender.org/D4148
NLA requires a usable default value for all properties that
are to be animated via it, without any exceptions. This is
the real cause of T36496: using the default of 0 for a scale
related custom property obviously doesn't work.
Thus, to really fix this it is necessary to support configurable
default values for custom properties, which are very frequently
used in rigs for auxiliary settings. For common use it is enough
to support this for scalar float and integer properties.
The default can be set via the custom property configuration
popup, or a right click menu option. In addition, to help in
updating old rigs, an operator that saves current values as
defaults for all object and bone properties is added.
Reviewers: campbellbarton, brecht
Differential Revision: https://developer.blender.org/D4084
Nice side-effect of using new __annotations__ thingy to store
dynamically-generated fields in a class: __annotations__ dict is not
ensured to exist for a given class, so we may end up modifying on of the
parents' one!
Ensure we use lists for keymap items and item properties.
This means scripts can access keymap definitions from other layouts,
manipulating them without sometimes encountering a tuple that needs
to be converted into a list.
Use the same data format and loader that the default key-maps use.
This supports nested properties (needed for macros)
and fixes modal key-maps which weren't supported.
This format still needs to be documented.
bpy_extras were meant to be useful high-level helper functions for
script authors to perform common operations,
to avoid writing to verbose API's.
bpy_extras.keymap_utils contains some specialized API calls
mainly intended for Blender's own internal use.
Move keymap import export to internal API.
Currently the filenames are used when setting keymaps.
This hard coded naming meant the preset and setting function
need to be kept in sync.
Prefer to not have hard coded replacements which need to be duplicated.
For Blender builtin configurations the option to choose the select mouse remains
and is now also in the splash screen. It works by changing the keymap dynamically
in the script, rather than using special events.
The system of automatic switching of events was not flexible enough to deal with
side effects that require further keymap changes, so it is now under more manual
control in the script.
This breaks compatibility for some scripts and exported key configurations.
These can be fixed by replacing SELECTMOUSE, ACTIONMOUSE, EVT_TWEAK_S and
EVT_TWEAK_A with appropriate LEFTMOUSE, RIGHTMOUSE, EVT_TWEAK_L and
EVT_TWEAK_R events.
Other than that, there should be no functional changes.
