Due to how we find kmi to remove and kmi to add when patching final keymap with user defines,
we could actually end up with same kmi for both, see comments in code for details.
Note that it may be a good idea to make user-defined customizations specific to a given base keymap,
instead of applying them blindly?
- Add blentranslation `BLT_*` module.
- moved & split `BLF_translation.h` into (`BLT_translation.h`, `BLT_lang.h`).
- moved `BLF_*_unifont` functions from `blf_translation.c` to new source file `blf_font_i18n.c`.
Needed for node insert offset (Auto-offset in UI), but kept separate so people notice it without having to check insert offset commit (not for commit ratio of course ;) )
We already had that for global keymaps (used e.g. to generate shortcuts for menu entries),
but this wasn’t possible for modal keymaps yet (e.g. help message in header during
transforms and other modal operation).
This commit only adds needing background code, it does not change anything from user PoV.
Modal operators will be updated to use it in comming weeks.
Thanks to Campbell for revisions & suggestions. :)
Differential Revision: https://developer.blender.org/D780
Our current keymap doesn't give us enough room to make such changes in
the event system. To fix small issues caused by this, we would need to do
drastic changes in Blender's keymaps and internal handling. It was worth
a try, but it didn't work.
I can write down a more descriptive statement in a few days, but for now
I need a break of this stuff.
Design task: T42339
Differential Revision: D840
Initial implementation proposal: T41867
Short description:
With this we can distinguish between holding and tabbing a key. Useful
is this if we want to assign to operators to a single shortcut. If two
operators are assigned to one shortcut, we call this a sticky key.
More info is accessible through the design task and the diff.
A few people that were involved with this:
* Sean Olson for stressing me with this burden ;) - It is his enthusiasm
that pushed me forward to get this done
* Campbell and Antony for the code and design review
* Ton for the design review
* All the other people that gave feedback on the patch and helped to
make this possible
A big "Thank You" for you all!
Issue is double here:
* Quite a handfull of menu entries actually diverge slightly from their shortcut
counterpart (often one has a prop explicitely set to its default value,
when the other keep it unset).
* Current code was actually basically sending 'is_strict' option into canal,
by doing a second check in `wm_keymap_item_find` setting unset op props
to their default value!
Now, is_strict mostly says one thing: "never consider an unset property as
equal to a set one". Even if set property matches default value. Default values
are not always the same things as unset ones, as demonstrated by this report.
So we are being much stricter now, and also have to check shortcuts and
menu entries definitions actually matches, added some code (triggered by
--debug-wm option) that prints when it finds some (potential) issue.
There is one exception though - Macros. Those have their whole prop set defined
in menu entries currently, this shall probably not be the case, but is another issue,
so for now for macro operators we always do non-strict comparison (pretty much
the same as previously, in this case).
Also 'enum' operators are still tricky. Currently, shortcut extraction relies on
`ot->prop` being set, so even if this is not aboslutely needed anymore (when defining
UI you can specify an arbitrary enum property by name), `ot->prop` shall be set.
Note fix commit for mismatches between menu entries and shortcuts is needed next.
`WM_keymap_guess_opname()` was missing a bunch of op 'types'/familly. Now all are there,
either trying to find a matching keymap, or explicitely listed in a comment as skipped for now.
Note matching might not be perfect in all case, but we can easily tweak that later if needed.
This commit merges the code in the pie-menu branch.
As per decisions taken the last few days, there are no pie menus
included and there will be an official add-on including overrides of
some keys with pie menus. However, people will now be able to use the
new code in python.
Full Documentation is in http://wiki.blender.org/index.php/Dev:Ref/
Thanks:
Campbell Barton, Dalai Felinto and Ton Roosendaal for the code review
and design comments
Jonathan Williamson, Pawel Lyczkowski, Pablo Vazquez among others for
suggestions during the development.
Special Thanks to Sean Olson, for his support, suggestions, testing and
merciless bugging so that I would finish the pie menu code. Without him
we wouldn't be here. Also to the rest of the developers of the original
python add-on, Patrick Moore and Dan Eicher and finally to Matt Ebb, who
did the research and first implementation and whose code I used to get
started.
Issue was caused by wm->defaultconf being NULL when in
background mode which made keymap modifications from a
script crash.
Reviewed by Brecht, thanks!
Remove KeyMap mode from outliner, was an old half-finished features redondant with user preferences settings...
Also moved key map item's "event type to map type" and map type defines at WM level, this is too much generic to be at RNA level.
Also added a check in versionning code to convert all outdated outliner modes to a valid one (seems old 'verse' ones were not handled as well).
Thanks to Brecht for reviews and advices!
When setting keymap properties to values equalling the RNA default, they will
get "unset" and automatic operator behavior is used. There is no way to
explicitly set the default value as a user.
1) To allow distinguishing uninitialized (not set) properties in the keymap
items, a few changes to the RNA struct comparison function are needed: Instead
of allowing only strict/non-strict comparison of 2 properties A and B in a
struct, this now has 3 modes:
* STRICT: compare only the actual property values (same as 'strict' before)
* UNSET_MATCH_ANY: if either A or B is unset, consider them a match (same as
non-strict before)
* UNSET_MATCH_NONE: if one property is set and the other not, consider them a
mismatch.
The new UNSET_MATCH_NONE mode is useful for keymaps, because it allows keeping
user-defined property values in the keymap even if they match the default
property value (see wm_keymap_diff function in wm_keymap.c)
2) A new operator is added for unsetting ID properties in the RMB context menu
and in user preferences next to keymap properties. This only works on ID
properties and deletes the ID property storage, so that the default value is used.
In the user preferences for keymaps the properties are shown in an inactive
layout to indicate that the default value is used (which some operators such as
the "select linked" op from the report use to trigger automatic behavior). When
the user sets a property it gets set and stays that way until explicitly "unset"
using the new operator.
