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

[Campbell Barton]

@Dalai, our own addons will come already packages with blender,
Importing a zipfile which contains a python package is also supported
by the install operator, though currently there is no way to
un-install, you have to manually remove from disk.

About having all io as addons,
At the moment the deciding factor for a script being enabled by
default is when its located scripts/io or scripts/op.
There is no need for this, we can make io scripts into addons and
enable some by default based on what we think are good formats to show
to the user (2.4x had formats like XFIG & OFF, I bet nobody used
these!).

@Matt, agree this is needed, (has been discussed for years!) but at
the moment I'm just looking at making changes before the next beta (1
week or so?).
This is definitely one of the integration issues I'll work on,
switching between operators on a single file selector, managing
multiple formats at once, using presets system for format defaults.

@Roger, I've not decided on exactly how to do this, probably use a
generic callback system which will replace scriptlinks.


On Wed, Sep 1, 2010 at 12:32 AM, Roger Wickes <rogerwickes at yahoo.com> wrote:
> In line with Matt's idea, we could set up import/export similar to the way the
> OS system chooses a codec.
>
> Each Import/Export would register it's extension when loaded. Then, when
> File->Import happens and
>
> a file is selected, the extension is matched against the list of available
> registered importer's
> extensions. If there are multiple importers claiming to handle the same
> extenstion, I suppose
> a popup (horrors) is in order to let the user choose which to use. The filespec
> would then be
>
> handed off to the importer to do its thing. If no one claims the extension, the
> popup would list all
> of them to let the user choose. Ultimately, an option would be to search the
> repository for a match,
>
> but that is a little out there...
>
>  --Roger
>
>
> Check out my website at www.rogerwickes.com for a good deal on my book and
> training course, as well as information about my latest activities. Use coupon
> Papasmurf for $15 off!
>
>
>
> ----- Original Message ----
> From: Thomas Dinges <dingto at gmx.de>
> To: bf-blender developers <bf-committers at blender.org>
> Sent: Tue, August 31, 2010 1:56:36 PM
> Subject: Re: [Bf-committers] Operator Import/Export (proposed changes)
>
>  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
>
>
>
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
- Campbell