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 <[email protected]>: > 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
