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.
ShrinkFatten operator now uses scale key to toggle 'Even thickness' option.
With the default keymap this is Alt+S,S.
Added functionality so the header print can get the key used for the modal keymap, some other operators should make use of this too.
comparing keymaps was too sloppy or too strict, now sloppy keymap comparison works by setting all the operator
properties to their default values if they are not already set, then compare this with the keymap item (ignoring values missing from either one).
... this way any non default keymap setting wont match with an operator menu item which doesnt set this operator at all (a problem sighted in this bug report).
developer notes:
- IDP_EqualsProperties_ex() function adds an argument to treat missing members of either group to act as if there is a match.
- WM_operator_properties_default() function to reset RNA values to their defaults.
- add IDP_spit(), debug only function to print out ID properties.
Double clicks were never working reliably in Blender - this mostly because
it wasn't a real event, but something generated in the handler code.
Now it is an actual event - meaning it always gets handled (if you have
a keymap item for it of course), but if there's no doubleclick handling
it treats the doubleclick as a normal click.
Also cleaned code. No recursion anymore.
