| Age | Commit message (Collapse) | Author |
|---|
|
Re-registering an operator used by the keymap would lead memory.
Reload scripts for eg leaked over ~1600 blocks.
|
|
|
|
|
|
|
|
Those unwrap operators are a bit tricky, some are available from both 3DView and UVEditor, others only from 3DView...
Hacked around this by returning Mesh keymap for UV_OT ops for specific 3DView/MeshEditMode context.
|
|
This commit merges all the work done in the GPencil_Editing_Stage3 branch
as of ef2aecf2db981b5344e0d14e7f074f1742b0b2f7 into master. For more details
about the changes that this brings, see the WIP release notes:
http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.77/GPencil
|
|
make it return kmi pointer directly.
All three usages of this func were only using kmi_id to find again kmi itself, pretty dumb!
|
|
Yet another Space/NoSpace mismatch when searching keymaps in WM_keymap_guess_opname().
Spent again some time trying to chase those, was the only one I found...
|
|
Definitions could shadow local vars.
|
|
reassign hotkey after removing it.
Anim Channels keymap is not editor-related...
|
|
UV Editor keymap is not bound to a given editor (spacetype)...
|
|
We need custom context here, those are often very short names so context collision is pretty easy.
Also some minor changes (and avoid shadowing varnames)...
|
|
|
|
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 ;) )
|
|
Previously you had to pass operator which in some cases might not be available or hard to get.
|
|
double-click.
I think this is the only Keymap value we really need to handle here...
|
|
|
|
for them.
|
|
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
|
|
|
|
Some of them are just brain dead code, some are potential bugs.
|
|
|
|
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.
|
|
Makes usage of those funcs much more clear, we even had mixed '!strcmp(foo, bar)'
and 'strcmp(foo, bar) == 0' in several places...
|
|
|
|
Own mistake in previous fix here, was too greedy in finding an existing kmi of UserPref add diff kmi, we only want
to ignore exact same kmi's here.
|
|
config profile
When patching a keymap with a 'UserPref' diff one, do not add keymap items from diff
if they already exists in patched keymap.
|
|
|
|
There was also an issue with passing sl->spacetype here, for some reason...
|
|
No need to search the whole string.
|
|
`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.
|
|
|
|
Opted to keep includes if they are used indirectly (even if removing is possible).
|
|
|
|
|
|
|
|
|
|
|
|
After some investigation with mont29, seems like the best way to ensure
keymaps point to valid operators is using WM_keyconfig_update().
|
|
|
|
|
|
Issue was caused by wm->defaultconf being NULL when in
background mode which made keymap modifications from a
script crash.
Reviewed by Brecht, thanks!
|
|
|
