On Wed, Apr 06, 2005 at 02:09:03PM -0700, Joshua A. Andler wrote:

...

...

I think it would be invaluable for 0.42 that this whole approach should be rethought and reimplemented in a clearer way.

Not just invaluable but mandatory, IMO. It's been a usability disaster.

Well, the question is, is there any possible way to have inkscape autodetect on startup to see if the appropriate dependencies are installed, and only give options to use them if they are available?

Possibly, although in some cases we provide a tool with the package, so the extension itself exists, but it may have a dependency to something else which does not exist. So it could get tricky to map exactly what the dependencies are.

Another possibility is to have it give a specific warning when you try to use a specific feature.

Yeah, although that could get annoying, and I think is probably contrary to HIG standards - if the application indicates that a feature is available but doesn't run it, then it opens the question in the user's mind about whether other features are going to actually work or not. Ideally, Inkscape should present only functionality that is guaranteed to work, but also provide some way for the user to also see 'potential' functionality along with explanations of what they'd need to do to activate it.

The idea we've kicked around is to create an 'Extensions Editor' dialog that has a tree view on the left pane with extensions shown, and on the right displays info about the item - whether it works, etc.

In general, we really need to get move folks involved in helping wrangle all the various extensions, and make sure they work properly. Since these are all 3-rd party things, there's a huge amount of variability between them, and I think we'll only succeed if we can distribute the work. I think an ideal situation would be if each extension had a person identified with it to help maintain it. Sponsor-an-extension, anyone? ;-)

And my last potential solution is that we need to package the necessary files to give inkscape this functionality natively. The first or last suggestions would be optimal in my opinion because you get the option to use formats on Windows, where the programs we depend on aren't available for it and they would both resolve that.

Unfortunately, while this may work for simple scripts, for anything more complex (such as Ghostscript, sketch, etc.) that gets too complicated.

Also, even with scripts we find issues occur with e.g., Perl or Python not being present, or (esp. on Windows) the script has a *nix hardcoded path that won't work on a Windows file system.

Anyway, all these are important issues that I think we need to get sorted out really well. In the Roadmap we've slated some upcoming releases to really focus on this whole issue, and I would urge anyone with an interest in this to consider doing some investigation and come up with ideas. Hopefully once the gtkmm work is behind us and 0.42 is out the door, we can really pour some thinking into it and solidfy things better.

Bryce