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

[Dalai Felinto]

3) View3D buffer queries (depth buffer, normal buffer, selection
buffer(s)...) from Python.

Depth buffer and color buffer are possible to get with bgl (the opengl
wrapper).

--
Dalai

2012/5/6 Dima Glibitsky <dima.glib at gmail.com>

> 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
> _______________________________________________
> Bf-python mailing list
> Bf-python at blender.org
> http://lists.blender.org/mailman/listinfo/bf-python
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/bf-python/attachments/20120506/5858a794/attachment.html>