On Sun, Feb 14, 2010 at 9:03 PM, Charles Wardlaw <cward...@marchentertainment.com> wrote: > Hi Campbell, > >> Hi Charles, your mail mostly covers installation issues which are >> important but not directly related to extensions. >> Since we want users to be able to add scripts weather we have some >> concept of an extension or not. > > Implementation-wise they might not be, but from a user-centric view > installation is THE spot where you end up getting the most headache and > support requests. I sell a commercial plugin through FUNHouse Interactive (a > company with a friend) and in beta testing the original version, the thing > that threw people off more than anything else was just getting the script > copied into the right place. > > Anyway I don't want to pull the conversation too far off-topic, but > management of locations is *crucial* to helping non-technical users work with > extensions / scripts. > >> Script dirs being accessible is more an platform issue, I think we >> should have some script installer in 2.5x since Mac especially makes >> this very tricky. > > An installer is a bit much, no?
> Not to mention, the installers would be a quagmire on each platform. On Mac, > I'd never want a user installing extensions into the App bundle (nor should > they have permissions to do so), and Vista locks down a lot of directories > (and often won't let you write to folders you own... grumble). A single > spot, perhaps one user-selectable, where people could drop in zip bundles or > single scripts (or even copy in whole folders) would circumvent all of those > issues. Plus, it'd save on coding an installer for each platform. :) By installer I mean a script thats probably 50-150 lines of code, all it needs to do is copy files from some place on the users hard disk to a user script folder, It can do some nice things like "Your scripts dir doesnt exist, would you like it to be created?", as well as extracting files from a zip. Martin wrote something like this for 2.4x. >> A script installer could easily extract a zip package into the extras dir >> too. > > Can't Python add a zip file to its system path like it would a regular > folder? Most users aren't going to want to modify Extensions -- they'll just > want to plug and play. Looking at the code would be a power user feature, > and power users can unzip the bundles themselves. :) py can comport zips http://docs.python.org/library/zipimport.html >> Rather not deal with extensions like dependencies of a linux package >> manager or something like this, if you like to add Gears often you can >> enable the gears script for eg. Will keep in mind that these problems >> may occur but also would like to keep this more as a way to add/remove >> functions from the interface rather then manage configurations of >> tools that might/might not be installed. > > At some point they may require that level of corralling, though. If I send a > series of Blends off to an external renderfarm and someone forgot to send > along one of the Extensions, Blender should complain and error out with the > name of the node and the script that is missing. > > I'm assuming that you'll be making Extensions keep a list of what they've > registered -- functions, menus, panels, object types, and so on -- so that > when they're unloaded all those things go with them. (Perhaps in the > __init__.py -- there could be tags like the ones in scripts in 2.49? Or even > a __bpyall__ = [...]) That info could be saved for dependent nodes with the > Blend file, so that files sent out could give proper error reports. This > information could be registered through the system by subclassing an > Extension class in the init and overloading Init() and Deinit() functions. the extensions well be saved as a list of module names. > I don't think you'd want dependencies between Extension packages, though, > like how linux works. It'd be one level -- files require Extensions x, y, > and z. > > However, this kind of management *is* more about adding / removing functions > than configuring tools. Extensions that export would show up in the export > menu; new constraints would show up in the Armature UIs, etc. It'll seem > like overkill for the smaller scripts but will allow much larger and more > complex things to be written later. Weather we call them extensions or not people will write scripts that integrate into blender and copy them into their scripts dir, I just proposed extensions as a way to enable and disable this, its really not that big of a deal but it means other problems still need solving. > Maybe this is also more complex than you were envisioning? If there are no > Extensions then it'd be a simple directory walk in the scripts folder, I > guess. Then again, a directory walk could examine files for tags like 2.49 > did, and if it finds a #BPYEXTENSION or something in the first line it could > treat the file differently. > > This is all just my opinion, you know. Since I won't be coding the feature, > that and testing are all I can offer. :) > >> I knew someone would pick on my list, aparently Nintendo DS use PCX images >> too! > > PCX? Now that's just weird. ;) > ~ C > > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- - Campbell _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
