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

[Roger Wickes]

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