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