- UILayout.popover(.. panel_type ..)
A single panel
- UILayout.popover_group(.. panel categories ..)
Expands all panels matching args.
Currently used in the topbar for redo and paint options.
- WM_manipulatorgrouptype_remove- > free
- WM_manipulator_group -> WM_manipulator_group_type
Naming here is still a bit confusing,
now at least free/remove are differentiated.
Initial support for Python/Manipulator integration
from 'custom-manipulators' branch.
Supports:
- Registering custom manipulators & manipulator-groups.
- Modifying RNA properties, custom values via get/set callbacks,
or invoking an operator.
- Drawing shape presets for Python defined manipulators (arrow, circle, face-maps)
Limitations:
- Only float properties supported.
- Drawing only supported via shape presets.
(we'll likely want a way to define custom geometry or draw directly).
- When to refresh, recalculate manipulators will likely need
integration with notifier system.
Development will be continued in the 2.8 branch
This addresses an issue raised by D2453 -
that there was no way to check if operators are run
multiple times in a row.
Actions are still ignored that don't cause an UNDO event.
This gives us 9 flags available again for properties (we had none anymore),
and also makes things slightly cleaner.
To simplify (and make more clear the differences between mere properties
and function parameters), also added RNA_def_parameter_flags function (and
its clear counterpart), to be used instead of RNA_def_property_flag for
function parameters.
This patch is also a big cleanup (some RNA function definitions were
still using 'prop' PropertyRNA pointer, etc.).
And yes, am aware this will be annoying for all branches, but we really need
to get new flags available for properties (will need at least one for override, etc.).
Reviewers: sergey, Severin
Subscribers: dfelinto, brecht
Differential Revision: https://developer.blender.org/D2400
Based on patch by @codemanx, but with slightly less verbose descriptions.
More detailed behavior etc. rather belongs to doc/python_api/examples/bpy.ops.x.py imho.
Make the UI API more consistent and reduce confusion with some naming.
mainly:
- API function calls
- enum values
some internal static functions have been left for now
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.
WM_keymap_add_item(keymap, "TEXT_OT_insert", KM_TEXTINPUT, KM_ANY, KM_ANY, 0);
<--- this catch-all key map item at the end of the Text Editor keymap was
gobbling all the key events for user-defined hotkeys added after it in the
keymap. This includes all hotkeys for new operators defined by addons (via
keymap.keymap_items.new()).
As a slightly hacky workaround for this, I've added an extra parameter to
keymap_items.new() which will force the newly added item to get added to the
start of the key map items list (i.e. with top priority). To enable, simply add,
head=True to keymap_items.new() calls. For example:
keymap.keymap_items.new("MY_OP_my_operator_id", type='E', value='PRESS',
alt=True, head=True)
This should be useful for cases where there are similar catch-alls, where it is
necessary to insert our item before the offending catch-all (without knowing
which one it is). However, in general, it's recommended not to use this, unless
all other methods (inlcuding choosing another key combination if your first
choice doesn't work) fails.
Note about long lines: I did not touch to two pieces of code (because I don’t see any way to keep a nicely formated, compact code, with shorter lines):
* The node types definitions into rna_nodetree_types.h
* The vgroup name functions into rna_particle.c
Diff Keymaps
User edited keymaps now no longer override the builtin keymaps entirely, but
rather save only the difference and reapply those changes. This means they can
stay better in sync when the builtin keymaps change. The diff/patch algorithm
is not perfect, but better for the common case where only a few items are changed
rather than entire keymaps The main weakness is that if a builtin keymap item
changes, user modification of that item may need to be redone in some cases.
Keymap Editor
The most noticeable change here is that there is no longer an "Edit" button for
keymaps, all are editable immediately, but a "Restore" buttons shows for keymaps
and items that have been edited. Shortcuts for addons can also be edited in the
keymap editor.
Addons
Addons now should only modify the new addon keyconfiguration, the keymap items
there will be added to the builtin ones for handling events, and not get lost
when starting new files. Example code of register/unregister:
km = wm.keyconfigs.addon.keymaps.new("3D View", space_type="VIEW_3D")
km.keymap_items.new('my.operator', 'ESC', 'PRESS')
km = wm.keyconfigs.addon.keymaps["3D View"]
km.keymap_items.remove(km.keymap_items["my.operator"])
Compatibility
The changes made are not forward compatible, i.e. if you save user preferences
with newer versions, older versions will not have key configuration changes that
were made.
