Is there any specific reason we have the Effects menu off by default?
From what I heard extensions now work even on Windows, so why not
enable them for the release?
If they don't work without Python installed, do we now have a nice dialog that shows up when you try to run an extension (NOT on running Inkscape :) and says you need to install the interpreter? With such a dialog or something similar, I would vote for enabling the Effects menu.
And in any case, I would like to remove the big "EXPERIMENTAL" in the preferences label. It conveys no information, just scares users away.
Thoughts?
On Sat, 2005-07-09 at 16:08 -0300, bulia byak wrote:
Is there any specific reason we have the Effects menu off by default? From what I heard extensions now work even on Windows, so why not enable them for the release?
If they don't work without Python installed, do we now have a nice dialog that shows up when you try to run an extension (NOT on running Inkscape :) and says you need to install the interpreter? With such a dialog or something similar, I would vote for enabling the Effects menu.
And in any case, I would like to remove the big "EXPERIMENTAL" in the preferences label. It conveys no information, just scares users away.
Thoughts?
Well, I have very mixed feelings on this.
On one hand, I think that there is a lot of useful features for users in the Effects menu. There is a lot of cool stuff you can do.
On the other hand, I'm not sure it is clean enough for general use. Things like the menu being out of order and some of the effects not working and providing adequate error messages. All fixable, but not code I would consider writing this late in the release process. I'm worried we have an expectations problem, Inkscape has gotten so clean in the interface, that the Effects menu would be very noticeable in its current state.
I guess, I think we should let Aaron have the choice. It's most his hard work that would be hidden.
--Ted
bulia byak wrote:
If they don't work without Python installed, do we now have a nice dialog that shows up when you try to run an extension (NOT on running Inkscape :) and says you need to install the interpreter? With such a dialog or something similar, I would vote for enabling the Effects menu.
There is no such message, but the idea would be to split the dreaded extension-errors.log file into pieces and display the message at use time if there is a failed dependency check. There could be a description property for each dependency as there is now for each effect, which could give a sensible message.
This brings up the problem of localization. The inx files are not translated. And if extensions turn into a seperate entities from the Inkscape project as they should, it would be a heavy burden for translators and script authors.
There is also a problem of crafting inx files in such a way that they convey the proper information for an extension to run on any platform withouth platform specific inx files. One such problem is the interpreter (for extensions that require one). How can python be found if it is called by python on linux and python.exe on windows? Other dependencies have the same problem.
Python is not the only interpreter that can be used to make extensions, any language can be used. So it is a problem that some sort of possible interpreter list is hardcoded into Inkscape.
Some extensions use shell scripts as wrappers. Is there a platform independent solution for this?
These things all need to be thought through, RFEed, and implemented.
There are numerous other issues. This doesn't make the extension system and effects menu any less powerful. But it does make them a work in progress and the user should know that.
Aaron Spike
Aaron and Sarah Spike wrote:
bulia byak wrote: There is also a problem of crafting inx files in such a way that they convey the proper information for an extension to run on any platform withouth platform specific inx files. One such problem is the interpreter (for extensions that require one). How can python be found if it is called by python on linux and python.exe on windows? Other dependencies have the same problem.
This could be less of a problem than it might seem. If the path includes the Python directory (which I believe the installer on win32 does, but someone should check that), then just running: python script.py Would in fact run the script on Windows (and I presume on Linux too). Another way would be to use ShellExecute on Windows (and execute the script directly) and hope file associations have been set up to open the scripts with the right interpreter (this is definitely done by the Python installer on Windows). ShellExecute might have some other problems though (I don't know whether or not input/output redirection would work for example), but those could probably be worked around if necessary.
There is also something called Windows Script Host, for which at least ActiveState apparently provides scripting engines for Perl and Python (and MS of course provides support for JScript and VBScript by default). But I never used this myself, so I have no idea how how easy this would be to use (but as far as I can tell there's a good chance this wouldn't be harder than simply running the script directly or some program with the script as a parameter). This would be VERY platform-specific though, and probably not necessary.
I'm less familiar with other scripting languages, so I can't comment on them, but presumably the above techniques would also work for them (as long as their installer sets the path and/or file associations).
participants (5)
-
unknown＠example.com -
Aaron and Sarah Spike -
bulia byak -
Jasper van de Gronde -
Ted Gould