[Bf-python] Blender-python API/functionality proposals

[Dima Glibitsky]

This is the list of functionalities I often find myself wishing
Blender's Python side to have:


1) Selection state of elements and active element of collections

1.a) bpy.types.MetaElement.select -- user can select/deselect
metaelements, but there's no way to get/set it from Python.

1.b) bpy.types.SplineBezierPoints.active,
bpy.types.SplinePoints.active -- likewise, Python scripts currently
can't get/set active spline point.

To be more general, every selectable element should have a "select"
property, and every collection that can have active item, should have
an "active" property.

1.c) Also, it would be nice if every collection of selectable elements
had a "selected" iterator (and, perhaps, a "total_sel" int property)
-- when there are many items, but only few of them are selected,
scripts operating on selections could benefit from that substantially.


2) User interface

2.a) An ability to set "emboss" property for all types of layout
elements, not just layout.prop() and layout.operator().

2.b) An ability to specify icons for items in bpy.props.EnumProperty().
E.g. as an optional fourth tuple element in items:
EnumProperty(items=[('VISIBLE', "Visible", "Apply to all visible
objects", 'RESTRICT_VIEW_OFF')])

2.c) An ability to override tooltips for layout elements. I often
encounter situations when I can write a generic operator or a generic
property definition to use in many places, so having context-specific
tooltips would be quite helpful.

2.d) A way to specify operator properties for layout.operator_enum(),
layout.operator_menu_enum() and layout.menu():
E.g. layout.operator_menu_enum(...) to return an OperatorProperties
object, which would set the corresponding properties for every
operator in the menu.
Also, I can think of another alternative: add an "operator_properties"
attribute to UILayout, so that all operators drawn within this layout
would "inherit" these properties.

2.e) Have an access to locale strings mapping -- this is useful for
localization-aware GL text drawing, composite texts/labels, etc. E.g.
WindowManager.translate(text, interface=True, tooltips=True) -- which
would return the translated (or not translated) string, depending on
use_international_fonts, use_translate_interface,
use_translate_tooltips.


3) View3D buffer queries (depth buffer, normal buffer, selection
buffer(s)...) from Python.
This is useful for writing (or, at least, prototyping in Python)
interactive tools that heavily rely on what user can see and click at.
Raycasting becomes too expensive when you need to consider an area
rather than just one pixel under the mouse, plus it doesn't account
for non-raycastable things like edges, vertices, bones, etc.
The API might look like RegionView3D.query_renderbuffer(x, y,
buffer_type = enum in {'DEPTH', 'NORMAL', 'SELECTION', ...}) -- which
would return a float, Vector, some ID key or other data depending on
the nature of the buffer.


4) bpy.app.handlers for Undo pushes and the Undo/Redo/History actions.
Some tools (such as macros recording or parametric modeling) require
to be aware of every single change that's happening to bpy.data, and,
as far as I know, Blender already stores the diff between the Undo
steps.
For example, bpy.app.handlers might have "undo_history_pre" and
"undo_history_post" lists; the corresponding callback might have
signature callback(diff_paths), where diff_paths is a list of property
paths that would change (or have been changed).
It's also important to have access to the list of Undo History entries
and the currently selected History entry -- e.g.
WindowManager.undo_history collection of UndoHistoryEntry objects;
UndoHistoryEntry might have attributes like "message" and
"diff(undo_history_entry)".


5) UUID for each bpy_struct instance inside a .blend file (or, at
least, for PropertyGroups and objects inheriting from ID). UUIDs seems
to be a long- and much-requested feature that, unfortunately, also
seems to require a significant rewrite of Blender. Anyway, it would be
good to at least have this point explained in the documentation (e.g.
in API Overview or in Gotcha's), so that requests like this won't pop
up anymore.

------------------------
dairin0d