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. :) > 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. :) > 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. 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. 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
