On 2008-February-25 , at 01:23 , Bryce Harrington wrote:
I agree that it would be great to have a menu item that led you to http://extensions.inkscape.org, and let you click on the page to install them. Like xpi's for Firefox, they could be a zip or gzip archive just renamed to make the association with Inkscape work. They could contain all the same stuff (.py and .inx files), just packaged up with a simple zip and rename operation. Clicking on the file would put it in /{home}/.Inkscape/Extensions on Linux or /Application Data/{username}/Inkscape/Extensions under windows (don't know about Mac, but you get the idea), and the rest would just work. Juca, I think the autoupdate option is a good second step, but lets take first steps first.
This is something I've thought about as well ever since we first implemented extensions. However, lately I've changed my mind. On most operating systems there are already good systems for deploying packages and automatic package updates to users (synaptic on Ubuntu, for instance), so we'd be putting a lot of effort into essentially reinventing an existing wheel, for just a few differences in capability.
As a counter to Firefox's admittedly sexy plugin system, consider that the vast majority of successful open source projects who *don't* implement their own unique package delivery systems, and just rely on the OS to do it, as is proper.
I think I disagree with you in this. What software does rely on packaging systems alone for its add-ons? The software which I know to do this on linux (python, perl, R) all have an internal package system that works just as well. Those deb/rpm packages are for convenience only, because indeed packaging systems are convenient (oh dear how much do I miss apt-get update!). Some other programs are split in several packages on linux (main program+language packs comes to mind) but are just bundled a single big one on other platforms (this is what we don't want to do anymore). The only projects I see which are largely modular and which rely entirely on the packaging system for it are X and the linux desktops (KDE, Gnome, etc).
Overall this highlights nicely one important point: how valuable is the cross platform aspect of Inkscape to the project? If "cross platformness" is a priority, then Inkscape should deal with its own add-ons itself, so that it does the same thing on all platforms (and documentation can be consistent, etc.). You can remark that the exceptions I cited above are X based OSes only, and IMHO they can be exceptions because of this: because all these OSes have packaging systems they can rely upon. (Based on the reading of your blog I think I know your personal opinion about this. I understand it and agree with you, but well, those MacBooks are so nice you know ;) )
My second point is that there is no need to make this thing fancy, it should just be "download and double click to install". Items can be downloaded from an online repository with a browser (that what they are for after all, no need to reinvent that). Opening the downloaded item with Inkscape would just copy it to the appropriate directory. Implementation may be simple too. I think Inkscape already has environment variables pointing to these location (e.g. ~/.inkscape/ templates, palettes etc. on linux). If it does not... well it should (and it'd make my life much easier for some OS X integration I'm planning :P) and it probably won't be hard. Provided the extensions are aware of the environment variables (which I think they already are) this could be done with input extensions and simple shell scripts. Like: <inkscape-extension> <_name>Gimp Palette Input</_name> <id>org.inkscape.input.gpl</id> <dependency type="executable" location="extensions">gpl_input.sh</ dependency> <input> <extension>.gpl</extension> <mimetype>text/gimp palette</mimetype> <_filetypename>Gimp Palette (*.gpl)</_filetypename> <_filetypetooltip>Gimp Palette</_filetypetooltip> </input> <script> <command reldir="path">gpl_input.sh</command> </script> </inkscape-extension> and #! /bin/sh rc=0 cp -f $1 $INKSCAPESHAREDIR/palettes/ || rc=1 exit $rc
There are probably some things wrong with the code above but you get the idea. Some file extensions may need to be tweaked a bit to ease recognition by Inkscape (such as the .xml keys or .zip extension packages) but other than that it seems straightforward (well... *seems* ;) ).
As for he updating process, I am not sure how useful this would be. One would get updated core extensions with each release of Inkscape. How frequently would an extension be updated in this lag of time? The real bonus of having extensions separate from the main code is, IMHO, to get new _functionality_ between the releases, not really to get more frequent updates. As for non core extension, getting new versions when they break should not be that hard. At least I don't think this is particularly needed at first.
Eventually, one argument against an extensions package is that it does not allow to choose among the extensions. The goal is to have a large number of extensions in the end, and I would not want the additional clutter (in the UI I mean) caused by many things I won't use (or if I should have everything, I might as well have both Inkscape and the extensions in one package). Inkscape extensions are typically small so they cannot be shipped each in their own package. Overall, I think extensions will be too numerous to be shipped in one package and too small to be worth packaging each independently.
OK, now I'm going to bed.
JiHO --- http://jo.irisson.free.fr/