[Bf-committers] Operator Import/Export (proposed changes)

[Dalai Felinto]

Hi Campbell,
I like the performance gains. And I think a lot of addons could
benefit from that.

A question though: on my understanding (correct me if I'm wrong)
currently the "Install Add-On" takes individual .py files and copy the
one file to the addons folder.
If we start producing "official" addons that relies on packaging
shouldn't we support a way to "install" this kind of addons as well?
maybe if you import a __init__.py if copy the whole folder recursively
or even a zip file? I wonder if Python has a standard way to handle
that.

> For the user it wont matter much but this means we can have addons show up in the menu
> by default without them being moved into another SVN repository.
I didn't get this point.

Cheers,
Dalai
--
http://blenderecia.orgfree.com


2010/8/31 Thomas Dinges <dingto at gmx.de>:
>  It has been done in C for performance reasons.
>
> Campbell, your proposal sounds good to me. +1
>
> Best regards,
> Thomas
>
> Am 31.08.2010 19:26, schrieb François T.:
>> except Collada for instance ? or do you consider porting the code to py ? I
>> actually never understood why it was done in C instead of py though ?
>>
>>
>>
>> 2010/8/31 Campbell Barton<ideasman42 at gmail.com>
>>
>>> There are some changes I planned for a while and should do sooner then
>>> later since our own scripts are meant as examples for new devs to
>>> follow.
>>> In brief the proposal is to have import/export be setup more like addons.
>>>
>>> - move from "io" directory to "op"
>>> - make each format into a package so "/op/io_obj/__init__.py, load.py,
>>> save.py"
>>>   (I'm not fussed on submodule names, we just cant use import.py since
>>> its a py keyword)
>>> - only define operators in __init__.py, delay importing read/write
>>> modules until the operators run
>>>   (so blender loads faster!)
>>>
>>> The main disadvantage I see with this is we don't have all files in a
>>> simple flat directory anymore, but faster load times are a big
>>> incentive for me.
>>>
>>> This is fairly straightforward, but there are some other things to
>>> consider while on the topic.
>>>
>>> The changes suggested above basically make these match how our addons
>>> work, we could just have all importers and exporters be addons, some
>>> enabled by default.
>>> For the user it wont matter much but this means we can have addons
>>> show up in the menu by default without them being moved into another
>>> SVN repository.
>>>
>>> I'd also like to use mix-in classes for Importers/Exporters, this
>>> means we can have generic invoke functions, not have to define
>>> filename property on each operator, and we could generalize options
>>> for batch import/export too.
>>> Simple patch which adds bpy.types.Operator.Export
>>>   http://www.pasteall.org/15353/diff
>>> ...this would be opt in since some scripts might want their own
>>> invoke, but for now we have duplicate invoke() functions for most i/o.
>>>
>>> --
>>> - Campbell
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>
>>
>>
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>