Effects on Win32 (and side note)
Okay... first off, I nuked my svn checkout, xmingw, and my gtklibs... Then brought everything back up-to-date and clean at that.
Cross-compiled for win32 and fired up inkscape on the win32 box. The error I reported yesterday persisted (about not finding python25.dll). I manually moved the dll file from the main inkscape dir into the python subdirectory where python.exe resides. This solved problem of not being able to find the dll.
However, effects still do not work. When I try to run effects (interpolate is my example here) I now get output stating: "python: can't open file 'share\extensions\interp.py': [Errno 2] No such file or directory"
For the sake of trying to find a workaround (like the dll), I copied the "share\extensions" directory structure with the contents into that python dir as well (hey it worked for the dll). Unfortunately, this did not fix it.
It seems like this may be more related to our library upgrade and new python than the changes Ted made. I really want to make sure that people will still be able to use effects on win32, and it seems like the sooner we can know if there's a problem, the better.
Anyone else building for/on win32 having a different experience? Again, note that I'm cross-compiling, not compiling natively.
Side note: Bob, the gtkrc file copied to "inkscape\etc\gtk-2.0" has the correct change I suggested. But, the gtkrc file that is in "inkscape\share\themes\MS-Windows\gtk-2.0" does not have the change and it is the one inkscape actually uses.
-Josh
P.S. Ted, you're getting CC'd because I want you to know that I plan on testing your changes on win32 asap... and also to know that I will bug you if your changes don't work on win32. ;)
Joshua A. Andler wrote:
Cross-compiled for win32 and fired up inkscape on the win32 box. The error I reported yesterday persisted (about not finding python25.dll).
I compile natively and get the same error.
I manually moved the dll file from the main inkscape dir into the python subdirectory where python.exe resides. This solved problem of not being able to find the dll.
Same.
However, effects still do not work. When I try to run effects (interpolate is my example here) I now get output stating: "python: can't open file 'share\extensions\interp.py': [Errno 2] No such file or directory"
Same.
Just wanted to note that I get the same issues, compiling natively, as Josh did, and hence rule out any possibility of his own incompetence ;)
Gail
Gail Banaszkiewicz wrote:
Joshua A. Andler wrote:
Cross-compiled for win32 and fired up inkscape on the win32 box. The error I reported yesterday persisted (about not finding python25.dll).
I compile natively and get the same error.
I never saw this one but I have python 2.5 installed on the computer besides with inkscape.
I manually moved the dll file from the main inkscape dir into the python subdirectory where python.exe resides. This solved problem of not being able to find the dll.
Same.
However, effects still do not work. When I try to run effects (interpolate is my example here) I now get output stating: "python: can't open file 'share\extensions\interp.py': [Errno 2] No such file or directory"
Same.
The issue seems to be related to the working directory. Is it possible to feed python full paths to our scripts on win32? Someone might want to try walking back up the directory with '..\share\extensions\interp.py'.
Aaron Spike
Aaron Spike wrote:
Gail Banaszkiewicz wrote:
Joshua A. Andler wrote:
Cross-compiled for win32 and fired up inkscape on the win32 box. The error I reported yesterday persisted (about not finding python25.dll).
I compile natively and get the same error.
I never saw this one but I have python 2.5 installed on the computer besides with inkscape.
Yeah, my guess is it finds the one in your $path.
However, effects still do not work. When I try to run effects (interpolate is my example here) I now get output stating: "python: can't open file 'share\extensions\interp.py': [Errno 2] No such file or directory"
Same.
The issue seems to be related to the working directory. Is it possible to feed python full paths to our scripts on win32? Someone might want to try walking back up the directory with '..\share\extensions\interp.py'.
Agreed that it seems to be related to the working directory... but wouldn't my copying the "share\extensions" stuff (with directory structure intact) to the python dir have potentially alleviated that (as it did for the dll)? I also temporarily added my inkscape dir directly in my $path and that didn't help anything either.
-Josh
Joshua A. Andler wrote:
Yeah, my guess is it finds the one in your $path.
Maybe. Python25 isn't in my path, but I'm not sure where python puts the dll so it might be.
Agreed that it seems to be related to the working directory... but wouldn't my copying the "share\extensions" stuff (with directory structure intact) to the python dir have potentially alleviated that (as it did for the dll)? I also temporarily added my inkscape dir directly in my $path and that didn't help anything either.
Ok, I missed you mentioning that you tried that. So what working directory is python seeing? I guess the only way to check that is to change the call to python to print that and recompile, no? Where was python.exe in old builds?
Aaron Spike
On Fri, 2007-06-29 at 08:09 -0700, Joshua A. Andler wrote:
Cross-compiled for win32 and fired up inkscape on the win32 box. The error I reported yesterday persisted (about not finding python25.dll). I manually moved the dll file from the main inkscape dir into the python subdirectory where python.exe resides. This solved problem of not being able to find the dll.
Good, I guess. You can override the place that Inkscape looks for python in your preferences, but we should get this right by default also.
I imagine that the way the path is searched changes slightly with the new function call. Before, I think the shell was doing it, but now I think GTK is doing it.
However, effects still do not work. When I try to run effects (interpolate is my example here) I now get output stating: "python: can't open file 'share\extensions\interp.py': [Errno 2] No such file or directory"
Please comment out the following lines in script.cpp:
907 /* 908 for (std::vectorstd::string::const_iterator i = argv.begin(); 909 i != argv.end(); i++) { 910 std::cout << *i << std::endl; 911 } 912 */
This will print out all the parameters being passed on execute. You should be able to see what exactly is being passed to python -- and give some good information there.
Also, you might try playing with:
917 Glib::spawn_async_with_pipes(Glib::get_tmp_dir(),
The call there is the working directory that things are called in. Perhaps on win32 that should be "C:\Program Files\Inkscape" or something?
--Ted
Ted Gould wrote:
Also, you might try playing with:
917 Glib::spawn_async_with_pipes(Glib::get_tmp_dir(),
The call there is the working directory that things are called in. Perhaps on win32 that should be "C:\Program Files\Inkscape" or something?
Ted,
Is it possible to call the scripts with the full path of the script?
Aaron Spike
Aaron Spike wrote:
Ted Gould wrote:
Also, you might try playing with:
917 Glib::spawn_async_with_pipes(Glib::get_tmp_dir(),
The call there is the working directory that things are called in. Perhaps on win32 that should be "C:\Program Files\Inkscape" or something?
Is it possible to call the scripts with the full path of the script?
How would said full path be determined? I always have my official release installed in "C:\Program Files\Inkscape", but then have various other development copies at other locations, my primary being "C:\inkscape".
If we can keep it relative to the parent directory, that would be optimal.
I am otherwise downloading a new build with the recommended change so I should be able to report back shortly with some info.
-Josh
Joshua A. Andler wrote:
Aaron Spike wrote:
Ted Gould wrote:
Also, you might try playing with:
917 Glib::spawn_async_with_pipes(Glib::get_tmp_dir(),
The call there is the working directory that things are called in. Perhaps on win32 that should be "C:\Program Files\Inkscape" or something?
Is it possible to call the scripts with the full path of the script?
How would said full path be determined?
That is exactly what I want to know.
If we can keep it relative to the parent directory, that would be optimal.
Then we will need to make that the working directory for shelling out to python.
Aaron Spike
On Fri, 2007-06-29 at 14:11 -0500, Aaron Spike wrote:
Joshua A. Andler wrote:
Aaron Spike wrote:
Ted Gould wrote:
Also, you might try playing with:
917 Glib::spawn_async_with_pipes(Glib::get_tmp_dir(),
The call there is the working directory that things are called in. Perhaps on win32 that should be "C:\Program Files\Inkscape" or something?
Is it possible to call the scripts with the full path of the script?
How would said full path be determined?
That is exactly what I want to know.
If we can keep it relative to the parent directory, that would be optimal.
Then we will need to make that the working directory for shelling out to python.
Would "INKSCAPE_EXTENSIONDIR" work in this case?
Is it dynamic on win32? For instance, does it work with multiple installs?
--Ted
On Fri, 2007-06-29 at 15:22 -0700, Ted Gould wrote:
How would said full path be determined?
That is exactly what I want to know.
If we can keep it relative to the parent directory, that would be optimal.
Then we will need to make that the working directory for shelling out to python.
Would "INKSCAPE_EXTENSIONDIR" work in this case?
Is it dynamic on win32? For instance, does it work with multiple installs?
Hmm, it looks like this is not really used in win32. In Linux this is configured by autotools to be the DATADIR plus an offset. But, it is also used by the autopackaging stuff -- where it is generated automatically. But, win32 moves all that stuff out.
I think the real solution here is to fix INKSCAPE_DATADIR and INKSCAPE_LIBDIR on win32 so that they are meaningful. That would help with other paths also.
--Ted
Aaron Spike wrote:
Ted Gould wrote:
Also, you might try playing with:
917 Glib::spawn_async_with_pipes(Glib::get_tmp_dir(),
The call there is the working directory that things are called in. Perhaps on win32 that should be "C:\Program Files\Inkscape" or something?
Ted,
Is it possible to call the scripts with the full path of the script?
Aaron Spike
Hi, AC:
Sorry if this email is poorly formatted. But apparently, nightly Thunderbird is a bit buggy. I'm typing this on PsPad. I've been trying to reply to the "win32/python" thread all day, but Thunderbird has been crashing.
The script path should always be relative to where Inkscape.exe is. That way we can have some consistency among shells and interpreters.
Python25.dll is not found by PATH. Rather, we want it to be in the default path of the executable. Why? To avoid version incompatibility problems. You should be able to have Python 2.4 or 2.6 on your box and not have problems with our Python 2.5 interpreter or environment.
We do not find Python.exe via PATH. What Inkscape does is to add /python to the application_path at startup. This is done via code that writes to the Registry at startup. /python and /perl are added to the application_path this way. This preempts PATH and basically has nothing to do with it. Also, the CurrentDirectory() on win32 is set to the directory where inkscape.exe is.
So, when Inkscape shells out, it is like: python some/script/path/script.py
...python.exe, python25.dll, and the script should all be found.
bob
On Sat, 2007-06-30 at 22:58 -0700, Ted Gould wrote:
On Sat, 2007-06-30 at 03:23 -0500, Bob Jamison wrote:
The script path should always be relative to where Inkscape.exe is. That way we can have some consistency among shells and interpreters.
So, how do we find this?
Is this it:
140 RegistryTool rt; 141 Glib::ustring fullPath; 142 Glib::ustring path; 143 Glib::ustring exeName; 144 if (rt.getExeInfo(fullPath, path, exeName)) {
Where fullPath would be the location of the inkscape.exe binary?
If so, can we change path-prefix.h to include a call to this somehow so that all the directories in Inkscape become full paths instead of relative ones. It would seem that would ensure that things would work correctly no mater how you initiated Inkscape.
--Ted
Bob Jamison wrote:
We do not find Python.exe via PATH. What Inkscape does is to add /python to the application_path at startup. This is done via code that writes to the Registry at startup. /python and /perl are added to the application_path this way. This preempts PATH and basically has nothing to do with it.
I remembered reading something like that in the code. Thanks for the explanation.
Also, the CurrentDirectory() on win32 is set to the directory where inkscape.exe is.
There are a few apparent bugs that result from this. Would it be possible to make the CurrentDirectory() the user's My Document folder when run from the gui, and set it to the current folder when envoked from the command line. Now that might not fix the problems with invocations inside of scripts unless they inherit My Documents from the environment of the gui process. If this is possible I think it might fix a few of the things that I've heard users complain were odd in the chatroom.
Aaron Spike
There is this nasty behaviour if I call Inkscape from an different directory than where the inkscape.exe is then Inkscape does not find all the share/ etc. directories.
Inkscape does not need to simply use the current worked directory but the directory where Inkscape.exe is. If that is possible.
Adib. -- Am Sonntag, den 01.07.2007, 07:41 -0500 schrieb Aaron Spike:
Bob Jamison wrote:
We do not find Python.exe via PATH. What Inkscape does is to add /python to the application_path at startup. This is done via code that writes to the Registry at startup. /python and /perl are added to the application_path this way. This preempts PATH and basically has nothing to do with it.
I remembered reading something like that in the code. Thanks for the explanation.
Also, the CurrentDirectory() on win32 is set to the directory where inkscape.exe is.
There are a few apparent bugs that result from this. Would it be possible to make the CurrentDirectory() the user's My Document folder when run from the gui, and set it to the current folder when envoked from the command line. Now that might not fix the problems with invocations inside of scripts unless they inherit My Documents from the environment of the gui process. If this is possible I think it might fix a few of the things that I've heard users complain were odd in the chatroom.
Aaron Spike
This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Adib Taraben wrote:
There is this nasty behaviour if I call Inkscape from an different directory than where the inkscape.exe is then Inkscape does not find all the share/ etc. directories.
Inkscape does not need to simply use the current worked directory but the directory where Inkscape.exe is. If that is possible.
Yes. I was thinking about this just after I clicked "Send".
Aaron Spike
participants (6)
-
Aaron Spike -
Adib Taraben -
Bob Jamison -
Gail Banaszkiewicz -
Joshua A. Andler -
Ted Gould