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 <[email protected]> To: bf-blender developers <[email protected]> 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<[email protected]> > >> 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 >> [email protected] >> http://lists.blender.org/mailman/listinfo/bf-committers >> > > _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
