Bug Description

I just downloaded the Windows executable installer for the inkscape release 0.46-pre0, which comes with its own python platform. As the summary says, I'm not able to get extensions working, any of them. Selecting a path and then running an extension only results in a console window popping up and nothing else, no changes whatsoever are done to the object, no errors are reported.

dunno if this can help, but trying to run the "colors marker to match stroke" extension on the 46pre1, i get a console backgound windows
with the path "C:\ programmes files\ inkscape\python.exe" and a pop-up saying something like "python.exe cannot be run because python24.dll cannot be found".

The fact is i have installed the 0.46 pre1 version of the desktop, so i think that the python path used is the one in my stable version of inkscape, 0.45.1, which would explain why he can't find python24.dll

Should i try to move the 0.46.pre1 version to c:\programme files\ to see if that helps ?
Anyway, inkscape should be able to run on any ohers directory that "C:\ programmes files\ inkscape\" ...

hi,
The downloaded Inkscape 0.46 does not seem to include an installer so I wrote a little .bat file to change the PATH before starting the program. The Effects then work because the python files are found.
runink.bat
set PATH="C:\directory\where\files\were\unzipped\inkscape\python";%PATH%;
set PYTHONPATH="C:\directory\where\files\were\unzipped\inkscape\python"
C:\directory\where\files\were\unzipped\inkscape\inkscape.exe

While several people have confirmed this, other windows users report having no issue. Additional investigation needs to be done to narrow in on what conditions result in the problem occurring. It sounds like this may be a packaging issue. Since it's a platform-specific issue and seems to occur only for a subset of that platform's users, I'm dropping the severity to High.

Also we still need an assignee for this issue. Unless someone takes ownership of this bug, we won't be able to accept it as a release blocker, but I'm leaving the milestone for now.

Been digging into this on vista with current SVN, installing python and lxml on the system level got it working, but only once I uninstalled 0.45 from my system.
However currently on vista invoking effects with only the inkscape python is actually crashing inkscape.

*** SOLUTION ***
it's not really a bug... it's related to the python installation, that's doesn't set a windows dos variable...
to solve it, simply add to the "PATH" variable, the full path to the python installed on the system.

As far as I am concerned, this is not a bug, it is an installation issue, which can probably be solved by a user.
I had the same problem myself when switching from Inkscape 45.1 to 46-devel. The problem was at least partly caused by the switch from python24.dll to python25.dll.
There are two different ways of tackling this : You can try a clean install where you remove all vestiges of the previous install, remove the \Inkscape\python\ directory, remove the \Inkscape\share\extensions\ directory, make sure python.exe is in the path, make sure there are no old .pyc files left lying around.
Second method is to install Python 2.5.1 for yourself directly off the net.
I've tried both methods, afaict they both work.
I would recommend the second method, for the following reason: In the newer versions of 0.46 the file import procedure has been largely taken over by the uniconv utility, which is really cool, but I think it is extremely unlikely that anyone will get uniconv to run on windows unless they have personally installed it for themselves off the net. (This in turn requires that you first have your own installation of Python as well.) At least that has been my experience so far, it is still a work in progress.
Anyways, to get to the point, I know that in principle these things are all supposed to be included in the package, but in practice you can simplify life a lot by just installing your own copy. It probably should not be necessary to do this, but on the other hand it is a very small price to pay for the added functionality you are getting, just my 2cts worth.

Ulf, I used your patch this goes into the right direction. I add pythonw.exe into the build. The other one modification is the build of a path inkscape/python/pythonw.exe instead of inkscape/pythonw/pythonw.exe. I think the key is PYTHONPATH in the environment. I have seen this in some other references in the web.

It works on my WinXP German also the envelope script. I have python installed but renamed the python Path to something else so I am shure it calls our inkscape python.

Umm, how does that (_win32_set_inkscape_env) relate to what registrytool.cpp is doing?
And by the way PYTHONPATH does not affect finding python(w).exe but affects from where modules are loaded (see http://docs.python.org/tut/node8.html)

2008/3/13, Ulferikson <email address hidden>:
>
> > Umm, how does that (_win32_set_inkscape_env) relate to what
> > registrytool.cpp is doing?
>
>
> It should have the same efftect.. but all users are not allowed to set
> HKLM registry keys. Another way to do the same is the runink.bat
> Lawrence suggested (and which I based the patch on).
>
>
> --
> [Win32] Extensions not working on Windows with rel 0.46-pre0
> https://bugs.launchpad.net/bugs/187290
> You received this bug notification because you are a direct subscriber
> of the bug.
>

This sounds like a good patch.
But by "should," do you mean that you have tested it? If so, we can
commit.

bob

Ulferikson wrote:
>> Umm, how does that (_win32_set_inkscape_env) relate to what
>> registrytool.cpp is doing?
>>
>
> It should have the same efftect.. but all users are not allowed to set
> HKLM registry keys. Another way to do the same is the runink.bat
> Lawrence suggested (and which I based the patch on).
>
>

As I asked earlier... Do you know that this works? If so, I will
commit it.

bob

Simon Dahlbacka wrote:
> Originator: No
>
> The patch in https://bugs.launchpad.net/inkscape/+bug/179683 changes HKLM to
> HKCU
>
>
> 2008/3/13, Ulferikson<email address hidden>:
>
>>> Umm, how does that (_win32_set_inkscape_env) relate to what
>>> registrytool.cpp is doing?
>>>
>> It should have the same efftect.. but all users are not allowed to set
>> HKLM registry keys. Another way to do the same is the runink.bat
>> Lawrence suggested (and which I based the patch on).
>>
>>
>> --
>> [Win32] Extensions not working on Windows with rel 0.46-pre0
>> https://bugs.launchpad.net/bugs/187290
>> You received this bug notification because you are a direct subscriber
>> of the bug.
>>
>>
>
>

ishmal:
> This sounds like a good patch.
> But by "should," do you mean that you have tested it?
> If so, we can commit.

By "should" I mean that the intention is the same (and also the result, *if* registrytool can set the AppPaths key). Yes, I have tested it. By first removing the AppPaths entries in the registry and commenting out the rt.setPathInfo line, I have working effects if I call _win32_set_inkscape_env and a crash with Glib::SpawnError otherwise.

before Inkscape closes it prints on my PC following message (see attached picture) "This application has requested the Runtime to terminate it in an unusual way ..." This text is english on my all german WindowsXP.
I googled and it came out with this:
This problem may occur when you use the /GR and the /MD compiler switches, and the version of the Msvcrt.dll file and of the Msvcirt.dll file is 7.0.x.
Note This problem does not occur when you use a version of the Msvcrt.dll file and of the Msvcirt.dll file that is earlier than 7.0.

http://msdn2.microsoft.com/en-us/library/ms997545.aspx
"The system supports "per application" paths. If you register a path, Windows sets the PATH environment variable to be the registered path when it starts your application. You set your application's path in the AppPaths subkey under the HKEY_LOCAL_MACHINE key."

> However, why do we even set PATH at runtime? Shouldn't
> that be handled by the installer and if so, then there
> are no permission issues?

Using an installer is probably the normal "recommended" way, but you still cannot set HKLM as regular user and if you build Inkscape from source you wouldn't use an installer at all.

> > the patch to (179683) Works For Me(tm) on Vista.
> > Haven't had the opportunity to try on XP.
>
> Do you really need the patch? It is too easy to oversee an AppPath or
> PATH pointing to a working python install. Make sure you cannot use
> extensions without the patch and then try again with.
>
>
Background info:
PATH: c:\mingw\bin;c:\devlibs\bin;C:\Program Files\MiKTeX
2.6\miktex\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;c:\Program
Files\Microsoft SQL Server\90\Tools\binn\;C:\Program
Files\Subversion\bin;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\PROGRA~1\ATT\Graphviz\bin;C:\Program
Files\Microsoft SQL Server\80\Tools\Binn\;C:\Program Files\Microsoft SQL
Server\90\DTS\Binn\;C:\Program Files\Microsoft SQL
Server\90\Tools\Binn\VSShell\Common7\IDE\;C:\Program
Files\Sandcastle\ProductionTools\;C:\Program Files 2\jEdit;C:\Program
Files\QuickTime\QTSystem\;C:\Program Files\Git\cmd

C:\Dev\Cpp\InkscapeSvn>reg query
"hklm\Software\Microsoft\Windows\CurrentVersion
\App Paths\inkscape.exe"
ERROR: The system was unable to find the specified registry key or value.

C:\Dev\Cpp\InkscapeSvn>reg query
"hkcu\Software\Microsoft\Windows\CurrentVersion
\App Paths\inkscape.exe"
ERROR: The system was unable to find the specified registry key or value.

Yes, I need that patch (or actually, preferably something that also works on
xp). Without it the following happens:
- python is still found (the correct one in /python sub dir next to
inkscape executable )
- For example the perspective effect fails followingly due to registrytool
cruft output on stdout

> > If App Paths indeed need to be in HKLM on xp, then my
> > patch is broken. I tried googling, but the information
> > about App Paths was really thin,
>
> I would use microsoft as reference on windows questions:
> http://www.google.com/search?q=site:microsoft.com+app+paths
>
> http://msdn2.microsoft.com/en-us/library/ms997545.aspx
> "The system supports "per application" paths. If you register a path,
> Windows sets the PATH environment variable to be the registered path when it
> starts your application. You set your application's path in the AppPaths
> subkey under the HKEY_LOCAL_MACHINE key."
>

ok, your googling skills were obviously better than mine then.

>
> > However, why do we even set PATH at runtime? Shouldn't
> > that be handled by the installer and if so, then there
> > are no permission issues?
>
> Using an installer is probably the normal "recommended" way, but you
> still cannot set HKLM as regular user and if you build Inkscape from
> source you...

> Yes, I need that patch (or actually, preferably something that also works on
> xp). Without it the following happens:
> - python is still found (the correct one in /python sub dir next to
> inkscape executable )
> - For example the perspective effect fails followingly due to registrytool
> cruft output on stdout

Ok. So the real problem is the output to stdout (you don't seem to need AppPaths or PATH to find python)? Maybe it is enough to direct all output to stderr? Try change printf(...) to fprintf(stderr, ...) in the registrytool

> > Yes, I need that patch (or actually, preferably something that also
> works on
> > xp). Without it the following happens:
> > - python is still found (the correct one in /python sub dir next to
> > inkscape executable )
> > - For example the perspective effect fails followingly due to
> registrytool
> > cruft output on stdout
>
> Ok. So the real problem is the output to stdout (you don't seem to need
> AppPaths or PATH to find python)? Maybe it is enough to direct all
> output to stderr? Try change printf(...) to fprintf(stderr, ...) in the
> registrytool
>

Since extensions are using temp files you probably need this patch as well. It comes from a bug that was marked as Vista only, but without the patch gdb gives me a run time error on WinXP (even though running inkscape without gdb doesn't) so there seems to be something fishy about those temp files.

Rygle, I have included the relevant glib source that is used for spawning a process (gspawn-win32.c). Now it works on my side (surprise). could you please doubblecheck on your side. If it works I will shape that up, so that we can include into the 0.46 branch. Adib.

There is i minor issue when applying the patch after the other .46 release patches has been applied, the file io/sys.h conflicts on the line
+#include <glibmm/spawn.h>
But just selecting <use text block from "mine" before "theirs" on the red line in Tortoise Merge fixes the conflict.
Be careful if you try to apply the patch from the command line.

To be sure what was going on, I right clcked on io/sys.h and selected "create patch", then when it comes up to select which files you can do a preview. This allows you to see what has previously been patched in since SVN checkout.

Building now on XP SP2 from a clean setup with all previous patches just added. Should be done in about 30 minutes. No complaints in build so far.

Something to keep an eye on. Just before this I did a build with the March 3 libs (without the comment 39 patch) plus the patched cairo files from Adrian. It seemed to build OK, but when I go to run "Report a Bug", I get the following;

========
Inkscape has received additional data from the script executed. The script did not return an error, but this may indicate the results will not be as expected.

python: can't open file 'D:\Download\Multimedia\Image\Inkscape\compiling\SVN\branches\Copy': [Errno 2] No such file or directory
========

This reflects on the earlier patches for path, and suggests to me that it can't handle paths with spaces, because that path should end with 'Copy of RELEASE_0_46_BRANCH\inkscape". The space after 'Copy' has confused it. Yes I know the path is a bit messy, but that's from running multiple Checkout directories. If you copy an existing Tortoise directory to a new one, it is copied with all the settings (ticks, crosses etc) in place. You probably knew that.

Actually, this build was in a directory without a space in the name, but as soon as I rename the inkscape directory to 'inkscape test', I get the same path error as with the March 3 lib build. The path fix patch needs to put the path in quotes or something like that.

With the Inkscape binary in a directory with a space in the name, I tested a few extensions;

Inset/Outset halo - OK - works perfectly
Render Grid - OK

Dimensions - no such file or directory upon apply
Extrude - no such file or directory
Interpolate - no such file or directory
Add Nodes - no such file or directory
Edge 3D - no such file or directory
Pattern Along Path - no such file or directory
Render barcode - no such file or directory

If I quit Inkscape, and then rename the directory back to without spaces, all work perfectly. Can you notice a pattern with the two that do work? Probably not important.

Weird - using Firefox 3.0b4 and every other patch file I've seen will open normally in it, but yours had no LF or CR, just one continual stream of text. But save as works fine. Actually, looking at the post, the attachment shows as "E:\ink\win32.046.quote.patch (3.2 KiB, text/html) ", where others are text/plain. Don't know why...Perhaps it's the < and > characters that got interpreted as html that the rest of that section is commented out to the browser.

Since you said his patch was lost, I tried to work off comment 13, and the build.xml stuff was only a small part of the earlier patch, so when I got a conflict I thought we would have to work through the conflict before trying the build.xml stuff.

Getting rid of the brief (>1sec) popup of a window is not the most important issue anyway. The real issue of paths has been sorted.

Any other thoughts? Otherwise we should commit this. I think this is the last issue that needs to be marked "Fix Released" before we can do a release.

> Any other thoughts? Otherwise we should commit this. I
> think this is the last issue that needs to be
> marked "Fix Released" before we can do a release.

How about creating a "master bug" for the win32 release? Mark it as dependent on the individual bugs, and start collecting/reworking patches such that they can be dropped in "packaging/win32/patches/" and be automatically applied.

I don't think we need an other bug.
1.) This bug (Extension not working) was because of path issues - people doubblechecked and confirn that it works on lib 20080303 version
2.) spawn bug https://bugs.launchpad.net/inkscape/+bug/204779 is addressed by "crash on help menu" introduced by lib 20080313 version
---
For 1.) everything is now in trunk (check trunk and get the diff to 0.46)
- main.cpp to set correct PATH and environment
- script.cpp to call pythonw and set the correct path to inkscape/python
- build.xml to include pythonw.exe into the inkscape-distrib directory

For 2.) the spawn bug we have a patch where I do not know anyone doubblechecked if that solves the problem
- script.cpp call inkscape::io::spawn
- sys.cpp redirect spawn call to glib::spawn or on win32 use the copied code
- sys.h declare inkscape::sys::spawn

All these patches have been committed to trunk and are available in the 0.46 branch at \packaging\win32\patches.

Just about to do a pre4 build on sourceforge, but still time to test a little more before a release in a day or two.

Is the unquote thing a problem (see 2 posts up from Ulf). If you think it might be a problem, how can we test this? What menu command, or process can we do to test? Need to be able to nail it down. Thanks!

Looks good. A few comments:
1) the "series" file contains a few TODO points that needs to be commented out or the apply_patches.sh script fails.
2) All patches can be applied automatically! :)
3) build.xml still doesn't have a line for pythonw.exe
4) It doesn't build for me since all _wspawn* are missing in the MinGW bundle I use.

(5. Less important, since we set PATH in the environment now, but the current code in registrytool,cpp doesn't do any good (but also no harm). AppPath has to be set in HKLM to work, but this isn't possible for all users and in that case any failure messages should be written to stderr or scripts will fail due to the unexpected messages on stdout. I think this has been fixed in trunk?)

Are you using the latest MinGW from Ishmal's site? I am, and I have no problem with builds like you described.

I think the _wspawn* stuff is defined elsewhere from your original patch. Adib did some include magic there, and I did follow it through yesterday, and it seemed that he had it all in, just in different places. Don't understand enough, but I think he was trying to do things more cleanly. He added some includes to process.h and wchar.h that are expected in the mingw bundle. Maybe that's your problem.

One of the patches has an entry for pythonw.exe, so this should be added once you patch. Patch 06 or 07 as I recall.

I'm just going to check out a complete fresh copy and patch and build, just to check.

I was just playing and python extensions work on WinXP OK for Inkscape 0.45+0.46pre0+devel, built Jan 15 2008 installed with an installer (and into Program Files) but not with the latest build (18125) from SVN (even after adding Python to the path).

All these fixes above are now committed to both trunk, and branch (under packaging/win32/patches).

To build branch, you will need the main source, plus apply the patches in that directory in order. Bryce wanted to keep the win32 stuff separate until properly test. It's all integrated in trunk though.

To build either using the March 13 devlibs, you will need the three dlls in that directory. Should work generally without them, but you will get bad prints and crash on radial gradient prints without the 3 newer dlls. A newer devlib package should be up in a few days, and then we'll change the build.xml file to match.

I believe this bug has been fixed, thank you very much !!
The Help menu item worked, the Effects | Color Custom menu item worked, I am impressed.
Just one question, I am still seeing a blank DOS window pop up temporarily as before, is this normal when using pythonw instead of python?

This should have been fixed last week in trunk (March 28 I believe), so I don't know why it's coming up in the April 2 build.

prkos: Are you having trouble with the 0.46 release version? The patch went into that well after trunk.

The DOS window is still a problem, and I thought the patches included above should have fixed it, but they didn't seem to, so I didn't include pythonw in the 0.46 release. It's only a minor irritation. Perhaps we could figure this out for 0.46.1, since it's mainly a packaging thing?

> The DOS window is still a problem, and I thought the patches included
> above should have fixed it, but they didn't seem to, so I didn't include
> pythonw in the 0.46 release. It's only a minor irritation. Perhaps we
> could figure this out for 0.46.1, since it's mainly a packaging thing?

I have been fiddling with this issue a bit today and it seems that
changing the build.xml to do -mconsole rather than -mwindows makes the DOS
window disappear (and thus takes popper use of pythonw).
PythonW.exe is now included in the build so this does not seem to be related
to packaging.

All these things are highly unclear, I downloaded Inkscape 0.46 today (2008-12-16) and still have crashing problems withe the "Effect" and "Help" menus. When starting the program as adminstrator (right-click, run as) crashing doesn't occur anymore but all effect "Modify Path" have no incidence on my drawnings.

which particular effect are you trying to run? Most of these effects require that you first select an object before running the effect. Some effects like Perspective and Envelope, may require that you select two objects.

To a shape I have designed. But the program won't let me do it since it
doesn't work on a squarre (which I draw with the squarre tool on the left
and that I select before trying to run the Edge 3D effect). I obviously have
a problem with the program.

2008/12/16 Alvin Penner <email address hidden>

> which particular effect are you trying to run? Most of these effects
> require that you first select an object before running the effect. Some
> effects like Perspective and Envelope, may require that you select two
> objects.
>
> --
> [Win32] Extensions not working on Windows with rel 0.46-pre0
> https://bugs.launchpad.net/bugs/187290
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Inkscape: A Vector Drawing Tool: Fix Released
>
> Bug description:
> I just downloaded the Windows executable installer for the inkscape release
> 0.46-pre0, which comes with its own python platform. As the summary says,
> I'm not able to get extensions working, any of them. Selecting a path and
> then running an extension only results in a console window popping up and
> nothing else, no changes whatsoever are done to the object, no errors are
> reported.
>
> I'm running Windows XP SP2.
>

To a shape I have designed. But the program won't let me do it since it doesn't work on a squarre (which I draw with the squarre tool on the left and that I select before trying to run the Edge 3D effect). I obviously have a problem with the program.

before you apply the 3D edge effect, try the following procedure : select the rectangle and apply the menu item Path | Object to Path.
Then make sure the rectangle is still selected and apply the 3D effect.

A lot of these effects require that the object be converted to a path using this procedure

Ok that works that way, only when I run the program as administrator - and
it only work partially, all of a sudden, the edges of the shape arn't in 3D
anymore... seem like a more 'basic' bug-

Thanks a lot, see ya !

2008/12/16 Alvin Penner <email address hidden>

> before you apply the 3D edge effect, try the following procedure : select
> the rectangle and apply the menu item Path | Object to Path.
> Then make sure the rectangle is still selected and apply the 3D effect.
>
> A lot of these effects require that the object be converted to a path
> using this procedure
>
> --
> [Win32] Extensions not working on Windows with rel 0.46-pre0
> https://bugs.launchpad.net/bugs/187290
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Inkscape: A Vector Drawing Tool: Fix Released
>
> Bug description:
> I just downloaded the Windows executable installer for the inkscape release
> 0.46-pre0, which comes with its own python platform. As the summary says,
> I'm not able to get extensions working, any of them. Selecting a path and
> then running an extension only results in a console window popping up and
> nothing else, no changes whatsoever are done to the object, no errors are
> reported.
>
> I'm running Windows XP SP2.
>

- did this work previously on Vista ?
- are there any error messages, what are the symptoms ?
- do you have your own version of Python installed, or are you using the Inkscape version ?
- can you go into a DOS window, type in the command 'python' from any directory and have the Python interpreter start up normally and tell you that it is Python 2.5.1 or whatever, with no error messages?

I can confirm a quirk but no error messages. I am not sure if the quirk is an error. In many of the releases, Inkscape 0.46+devel r20887 built Mar 12 2009 to Inkscape 0.46+devel r20921 built Mar 16 2009, the is a Create Bezier curve as a Spiro path. When a spiro bezier curve is created then extensions such as Modify Path->Add Nodes are run there is no change to the path and no error message is produced. If the path is selected then Path->Path Effects -> Remove Path Effects is done then the Add Nodes is done there will be new nodes added. The same lack of change occurs with Modify Path -> Jitter nodes until the Remove Path Effects is run.

Should Modify Path work on Bezier curves if they have a path effect?

When clicking on Help->Inkscape Manual a message window pops up quickly to say something like "Working" then a large black window (Dos/python?) opens and closes quickly but no manual shows up. The already open browser windows do not show a manual.

If this is situation JazzyNico is writing about then in my opinion a new bug report should be opened and this one should be closed because this situation does not seem like the original bug situation.

On Vista, I have installed Inkscape 0.46 (with the normal installer), build 20884 and build 20921 (and some older ones, installed manually in different directories). No separate Python installed on this computer.
With 20884 and 0.46, I have no problem. But with 20921, Inkscape crashes (runtime error, exactly the same as http://launchpadlibrarian.net/12697734/extension.png) each time I open a python extension or help menu item.
I have no access to this computer now. I try to give you more details (DOS errors) this evening.

the last comment, /63, is probably the more user-friendly method to use.
- in either case it will be necessary to make sure that the python.exe file is in the path, so that you can execute the command 'python' from a DOS prompt

Emergency save activated!
Emergency save completed. Inkscape will close now.
If you can reproduce this crash, please file a bug at www.inkscape.org
with a detailed description of the steps leading to the crash, so we can fix it.
----
It seems to use the right python version.
As I have no python installed (except with inkscape), there's nothing about it in my PATH.

Yes. Builds 20844, 20921 and 20932 are unzipped on my computer (in different directories), and the last working one is 20844 (I can still use it without any problem).

> if you open a DOS window using cmd and then run Python, or if you type in the command 'python' in the Run command window, does Python start up normally?

Python isn't in my PATH env (and doesn't really need to), so I have to use the whole path in the command line. I've tried python.exe and pythonw.exe, and they both return me an error popup, telling me pyrhon25.dll is missing. I have the same behaviour with working builds, so I guess it's not related to our bug.

Inkscapec tells us RegistryTool could'nt set a value after invoking gspawn. It reminds me of this comment: https://bugs.launchpad.net/inkscape/+bug/187290/comments/20.
I'll try to debug it with regmon as soon as possible.
I'm sorry the debug process is quite slow, but I have access to my Vista laptop on the evening only, and it works well with all my other computers.

Same behaviour as administrator.
I've traced with procmon inkscape.exe and gspawn-win32-helper.exe.
Both file are attached : 20844 shows inkscape working well, 20932 inkscape crashing.
The main difference is that in 20932, gspawn first creates a thread without creating a process first.
That's all I can say.