[Bf-funboard] Apricot Feature Request List (condensed)

[Campbell Barton]

The thing about defining your own window type or object type, is that
it only needs to look like a different object type.
in the case of crystalspace, extending empties drawtypes is probably
fine - as well as having a nice way for users to add different object
types that can be defined by crystalspace or another tool.

The same goes for window types, it would be nice to be able to
register custom window types to display in the menu. Internally this
can be the script window type. but as long as it acts like a new
window type I think this is enough.

We have discussed a generic 'Modding' system for Blender, so a python
module/class, can register window types, panels, object types, id
property templates for different object types.
In the short term this could be added as a python api, with
Draw.RegisterPanel(...), RegisterTemplate, etc but this needs to be
planned with blender 2.5 in mind.

On Thu, Mar 13, 2008 at 12:33 PM, Toni Alatalo <antont at kyperjokki.fi> wrote:
> From: "Campbell Barton" <ideasman42 at gmail.com>
>
> > http://apricot.blender.org/?page_id=14
>  >
>  i'm curious about the exact needs for "user defined objects" (first list
>  item :)
>
>  -- when we've talked about it earlier (at least with Genjix) and from
>  what I have encountered so far in our own work, basically
>  functionalitywise the current empties cover the need *apart from the
>  typing & looks*, i mean that marking locations and rotations with added
>  information suffices. so the additional need has been to nicely have
>  different types of such markers, and that could be achieved with e.g.
>  empty (draw)types or some such solution..?
>
>  so am wondering if there is some need that i'm not aware of, that would
>  need user defined / custom objects in the sense that they would be
>  actual new blender object types - that blender internally would handle
>  somehow specially, that would perhaps have some special behaviour etc.
>
>  or would kind of 'subtypes' of empties, that are basically just empties
>  to the blender core, still suffice. just that they would be drawn based
>  on that marker type, and the exporter would handle them and their data
>  specific to the 'subtype'.
>
>  early on when i started looking into Blender from a Python library
>  perspective i was of course fancying a model where you could just
>  subclass Blender.Object and define custom anything for your own Blender
>  object types, but that was for fun & curiousity, is far from trivial
>  with the architecture, and i don't know any actual uses for it yet :)
>
>  > - Campbell
>  >
>
>  ~Toni
>  _______________________________________________
>  Bf-funboard mailing list
>  Bf-funboard at blender.org
>  http://lists.blender.org/mailman/listinfo/bf-funboard
>