[Win32] Extensions not working on Windows with rel 0.46-pre0

[Fabio Alemagna]

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.

[Tom Davidson (tjd-mit)]

Is this a dupe of bug 178022, which is assigned to ishmal? If so, probably better to up that one to critical and milestone it, since it has an assignee (and a diagnosis of the problem)

[Bryce Harrington (bryce)]

In order for this to remain milestoned, we must have an assignee for the bug, who will take ownership of getting it fixed.

We cannot block the release on platform-specific bugs that have no owner.

[nightrow (jb-benoit)]

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\" ...

If this is not related exactly to the current bug(not sure), sorry :/

[Lawrence (annon0m0s)]

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

Hope this helps.

[Bryce Harrington (bryce)]

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.

[ScislaC (scislac)]

I know that Ted has been looking into Extensions as well as ACSpike & Ishmal... hopefully we can get a status update soon.

[John Cliff (johncliff)]

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.

[Ted Gould (ted)]

This sounds like a windows installer thing, more than an extensions one. Extensions seem to be working in general, and wouldn't effect whether the python24.dll is found.

[pbaggio (pierangelo-baggio)]

*** 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.

for example:

- situation -
python path: C:\Python25
PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\Programmi\PhpCli;C:\Programmi\7-Zip

- solution -
PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\Programmi\PhpCli;C:\Programmi\7-Zip;C:\Python25

[John Cliff (johncliff)]

umm, it is a bug, cos we dont use a python installer. we bundle a python install with inkscape and its not getting detected.

[Alvin Penner (apenner)]

    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.

[Ulferikson (ulferikson)]

Will you still be able to have trunk, branch and release versions of Inkscape side by side with a "normal" python install on the same machine if the installer sets the PATH variable?

Attached is a patch that sets the PATH variable during runtime instead.

[theAdib (theadib)]

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.

Adib.

[theAdib (theadib)]

I put that into trunk Revision 17875 to let people test on daily build. Check that you get inkscape/python/pythonw.exe. Adib.

[Simon Dahlbacka (simon-dahlbacka)]

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)

[Ulferikson (ulferikson)]

> 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).

[Simon Dahlbacka (simon-dahlbacka)]

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 (ishmalius)]

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).
>
>

[ishmal (ishmalius)]

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.
>>
>>
>
>

[Ulferikson (ulferikson)]

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.

Simon Dahlbacka:
> The patch in https://bugs.launchpad.net/inkscape/+bug/179683
> changes HKLM to HKCU

Interesting.. Is this new in Vista? For WinXP AppPaths must be in HKLM. That patch does not work for me.

[Simon Dahlbacka (simon-dahlbacka)]

the patch to (179683) Works For Me(tm) on Vista. Haven't had the opportunity to try on XP.

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, the other possibility would be that I s*ck at googling..

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?

[theAdib (theadib)]

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.

reference : http://support.microsoft.com/?scid=kb%3Ben-us%3B884538&x=6&y=8

The libs prior 20080313 are working on my pc. So this sounds as an dll-nightmare .!?

Adib.
---

[Ulferikson (ulferikson)]

> 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.

> 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."

> 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.

[Ulferikson (ulferikson)]

Adib,
Maybe you can update your patch with the changes you have made to trunk lately? That would make it easier to have the same applied to the 0.46 release branch when/if accepted.

[Simon Dahlbacka (simon-dahlbacka)]

On Tue, Mar 18, 2008 at 10:57 AM, Ulferikson <
<email address hidden>> wrote:

> > 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

Traceback (most recent call last):

  File "C:\Dev\Cpp\InkscapeSvn\inkscape\share\extensions\perspective.py",
line 129, in <module>
    e.affect()
  File "C:\Dev\Cpp\InkscapeSvn\inkscape\share\extensions\inkex.py", line
154, in affect
    self.effect()
  File "C:\Dev\Cpp\InkscapeSvn\inkscape\share\extensions\perspective.py",
line 72, in effect
    q[query] = float(f.read())
ValueError: invalid literal for float(): RegistryTool: Could not create the
registry key 'SOFTWARE\Microsoft\Windows\CurrentVersion\App
Paths\inkscape.exe'

363.34074

> > 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...

[Ulferikson (ulferikson)]

> 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

[Simon Dahlbacka (simon-dahlbacka)]

On Tue, Mar 18, 2008 at 11:02 PM, Ulferikson <
<email address hidden>> wrote:

> > 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
>

Ok that seems to work for me, I've attached that patch to
https://bugs.launchpad.net/inkscape/+bug/179683/comments/13

>
> --
> [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.
>

[Ulferikson (ulferikson)]

Attached is a patch for the 046 release branch containing this fix + the correction in Bug #203900 and also Simon's fix for Bug #179683.

[Ulferikson (ulferikson)]

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 (rygle)]

I've tried building a clean SVN 17979 with these patches and trying to do lots of stuff in the effects menu still results in a crash with no output using gdb, but I get this with inkcl

return code: 3
terminate called after throwing an instance of 'Glib::SpawnError'

I think this may be related to the newly registered bug https://bugs.launchpad.net/inkscape/0.46.x/+bug/204779 - they're talking about an upstream problem with glib.

[Rygle (rygle)]

I've tried building a clean SVN 17979 with these patches and trying to do lots of stuff in the effects menu still results in a crash with no output using gdb, but I get this with inkcl;

return code: 3
terminate called after throwing an instance of 'Glib::SpawnError'

I think this may be related to the newly registered bug https://bugs.launchpad.net/inkscape/0.46.x/+bug/204779 - they're talking about an upstream problem with glib.

Interestingly it doesn't crash with the inset/outset halo command.

[theAdib (theadib)]

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.

[Rygle (rygle)]

Once I returned to the March 3rd libraries this is fine. I will see if I can build with this patch and the newer libraries later today.

[Rygle (rygle)]

If anyone would like to patch, build and test, but is a little uncertain how, I have updated the wiki with my latest methods of building and testing on Windows - http://wiki.inkscape.org/wiki/index.php/Win32Port

Once you've compiled, here's how to use gdb to test

* Run a command window/shell (Start menu -> Run -> command)
* Enter the compiled inkscape directory and type the following;
     ..> gdb (enter)
     (gdb) file inkscape.exe inkscape.dbg (enter)
     (gdb) run {filename optional} (enter)

I always get a segfault to do with xsldebugstatus, but I then type continue (enter) and it always runs OK.

For some reason you can't open files normally from within Inkscape under gdb, so I always have to import them. Everything else works pretty normally.

If you get an error, go to the command window and type;
     (gdb) bt (enter)

This will give you a backtrace of what is going on inside the code. Check that no-one has put in the same result before. Then copy the text from this window and paste into the bug report.

[Rygle (rygle)]

Adib: Trying to build against March 13 libs. Patched with no errors, but I get this message halfway through build;

==========
Make error line 195: problem compiling: src/extension/implementation/script.cpp:
 In function 'gboolean Inkscape::Extension::Implementation::read_helper_report(i
nt, gint*, GError**)':
src/extension/implementation/script.cpp:982: warning: comparison between signed
and unsigned integer expressions
src/extension/implementation/script.cpp:1018: warning: comparison between signed
 and unsigned integer expressions
src/extension/implementation/script.cpp: In function 'gboolean Inkscape::Extensi
on::Implementation::do_spawn_directly(gint*, gboolean, GSpawnFlags, gchar**, cha
r**, char**, void (*)(void*), void*, void**, GError**)':
src/extension/implementation/script.cpp:1248: error: '_wspawnvpe' was not declar
ed in this scope
src/extension/implementation/script.cpp:1250: error: '_wspawnvp' was not declare
d in this scope
src/extension/implementation/script.cpp:1253: error: '_wspawnve' was not declare
d in this scope
src/extension/implementation/script.cpp:1255: error: '_wspawnv' was not declared
 in this scope
src/extension/implementation/script.cpp: In function 'gboolean Inkscape::Extensi
on::Implementation::do_spawn_with_pipes(gint*, gboolean, const gchar*, gchar**,
char**, GSpawnFlags, void (*)(void*), void*, void**, gint*, gint*, gint*, gint*,
 GError**)':
src/extension/implementation/script.cpp:1384: warning: deprecated conversion fro
m string constant to 'gchar*'
src/extension/implementation/script.cpp:1386: warning: deprecated conversion fro
m string constant to 'gchar*'
src/extension/implementation/script.cpp:1436: warning: deprecated conversion fro
m string constant to 'char*'
src/extension/implementation/script.cpp:1441: warning: deprecated conversion fro
m string constant to 'char*'
src/extension/implementation/script.cpp:1451: warning: deprecated conversion fro
m string constant to 'char*'
src/extension/implementation/script.cpp:1455: warning: deprecated conversion fro
m string constant to 'char*'
src/extension/implementation/script.cpp:1465: warning: deprecated conversion fro
m string constant to 'char*'
src/extension/implementation/script.cpp:1469: warning: deprecated conversion fro
m string constant to 'char*'
src/extension/implementation/script.cpp:1478: warning: deprecated conversion fro
m string constant to 'char*'
src/extension/implementation/script.cpp:1480: warning: deprecated conversion fro
m string constant to 'char*'
src/extension/implementation/script.cpp:1483: warning: deprecated conversion fro
m string constant to 'char*'
src/extension/implementation/script.cpp:1485: warning: deprecated conversion fro
m string constant to 'char*'
src/extension/implementation/script.cpp:1488: warning: deprecated conversion fro
m string constant to 'char*'
src/extension/implementation/script.cpp:1490: warning: deprecated conversion fro
m string constant to 'char*'
src/extension/implementation/script.cpp:1547: error: '_wspawnvpe' was not declar
ed in this scope
src/extension/implementation/script.cpp:1549: error: '_wspawnvp' was not declare
d in this scope
src/util/glib-list-iterators.h: In member function 'T* const&...

[Rygle (rygle)]

I tried putting the following in near the start of the patch

=========
#define _wspawnv
#define _wspawnve
#define _wspawnvp
#define _wspawnvpe
=========

This gets rid of the "error: '_wspawnvpe' was not declared in this scope" etc errors during build, but then a whole lot more come up.

=========
Make error line 195: problem compiling: src/extension/implementation/script.cpp:
 In function 'gboolean Inkscape::Extension::Implementation::read_helper_report(i
nt, gint*, GError**)':
src/extension/implementation/script.cpp:986: warning: comparison between signed
and unsigned integer expressions
src/extension/implementation/script.cpp:1022: warning: comparison between signed
 and unsigned integer expressions
src/extension/implementation/script.cpp: In function 'gboolean Inkscape::Extensi
on::Implementation::do_spawn_directly(gint*, gboolean, GSpawnFlags, gchar**, cha
r**, char**, void (*)(void*), void*, void**, GError**)':
src/extension/implementation/script.cpp:1252: warning: left-hand operand of comm
a has no effect
src/extension/implementation/script.cpp:1252: warning: right-hand operand of com
ma has no effect
src/extension/implementation/script.cpp:1252: warning: right-hand operand of com
ma has no effect
src/extension/implementation/script.cpp:1252: error: invalid conversion from 'co
nst wchar_t**' to 'int'
src/extension/implementation/script.cpp:1254: warning: left-hand operand of comm
a has no effect
src/extension/implementation/script.cpp:1254: warning: right-hand operand of com
ma has no effect
src/extension/implementation/script.cpp:1254: error: invalid conversion from 'co
nst wchar_t**' to 'int'
src/extension/implementation/script.cpp:1257: warning: left-hand operand of comm
a has no effect
src/extension/implementation/script.cpp:1257: warning: right-hand operand of com
ma has no effect
src/extension/implementation/script.cpp:1257: warning: right-hand operand of com
ma has no effect
src/extension/implementation/script.cpp:1257: error: invalid conversion from 'co
nst wchar_t**' to 'int'
src/extension/implementation/script.cpp:1259: warning: left-hand operand of comm
a has no effect
src/extension/implementation/script.cpp:1259: warning: right-hand operand of com
ma has no effect
src/extension/implementation/script.cpp:1259: error: invalid conversion from 'co
nst wchar_t**' to 'int'
src/extension/implementation/script.cpp: In function 'gboolean Inkscape::Extensi
on::Implementation::do_spawn_with_pipes(gint*, gboolean, const gchar*, gchar**,
char**, GSpawnFlags, void (*)(void*), void*, void**, gint*, gint*, gint*, gint*,
 GError**)':
src/extension/implementation/script.cpp:1388: warning: deprecated conversion fro
m string constant to 'gchar*'
src/extension/implementation/script.cpp:1390: warning: deprecated conversion fro
m string constant to 'gchar*'
src/extension/implementation/script.cpp:1440: warning: deprecated conversion fro
m string constant to 'char*'
src/extension/implementation/script.cpp:1445: warning: deprecated conversion fro
m string constant to 'char*'
src/extension/implementation/script.cpp:1455: warning: deprecated conversion fro
m string constant to 'char*'
src/extension/implementation/script.cpp:1459: warning: deprecated...

[Ulferikson (ulferikson)]

This is the patch from Adib moved into io/sys.cpp and the prototypes for _wspawn* added (seems to be missing in mingw).

I was using an older devlibs earlier and never saw this error. Using the latest devlibs I too had a Glib::SpawnError. The patch solves it for me.

[Rygle (rygle)]

Ulf, thank you for moving this forward. You're a champion!

I will test ASAP.

[Albin Sunnanbo (albin-sunnanbo)]

With the patch in https://bugs.launchpad.net/inkscape/+bug/187290/comments/39 the python extensions work again on Vista SP1.

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.

[Rygle (rygle)]

Did exactly that with Tortoise, but thanks for the warning.

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.

Will test again when this build is finished.

[Rygle (rygle)]

The patch works perfectly, but consequently I can't test the path problem the same way. Have to go through the extensions.

[Rygle (rygle)]

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.

[Rygle (rygle)]

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.

[Rygle (rygle)]

Just thinking, the space in the directory name thing will be quite bad if people install it into C:\Program Files\...

But hopefully easy to fix.

I had a quick look at the http://launchpadlibrarian.net/12761523/E%3A%5Cink%5Cwin32.046.path_env.patch patch, but I can't see anything obvious to my untrained eye.

[Ulferikson (ulferikson)]

This patch might help with the quote issue. I've also included the pythonw fixes Adib posted earlier since those seems to have been lost.

[Rygle (rygle)]

Have attached the spawn patch to the correct bug report (https://bugs.launchpad.net/inkscape/0.46.x/+bug/204779), assigned it to Bryce, marked as fix released and asked him to commit it. Unless one of you with access can commit it yourself and save Bryce the hassle.

Can we now keep using this bug to fix any minor remaining problem/s with the environment patch?

* Relevant patches *
https://bugs.launchpad.net/inkscape/+bug/187290/comments/30 - environment patch
https://bugs.launchpad.net/inkscape/+bug/187290/comments/31 - temp file patch

* Known Remaining Problems *
- Spaces in path cause python to complain "Can't open file...no such file or directory" error

[Rygle (rygle)]

Thanks for the patch, but it's a bit messed up because all the lines run together. Trying to reconstruct, but I may not be successful.

[Rygle (rygle)]

Patched by hand, python working well. Still get shell window briefly

Your patch didn't have that all of Adib's earlier patch from https://bugs.launchpad.net/inkscape/+bug/187290/comments/13
When I try to load that patch, it has conflicts in main.cpp with later stuff from the patch found here - https://bugs.launchpad.net/inkscape/+bug/187290/comments/30

[Rygle (rygle)]

Here's Ulf's patch cleaned up. Didn't put in the pythonw stuff from Adib as I couldn't figure out the conflicts.

[Rygle (rygle)]

If someone could figure out the conflicts between the patches, then I think we have everything pretty much ready to do our Win32 release.

* https://bugs.launchpad.net/inkscape/+bug/187290/comments/13 - Adib's original pythonw patch
* https://bugs.launchpad.net/inkscape/+bug/187290/comments/30 - Ulf's later environment patch.

The conflicts are in the main.cpp file.

[Ulferikson (ulferikson)]

> it's a bit messed up because all the lines run
> together.

Maybe the patch for build.xml looks too much like html for your webbrowser? Right-click and Save as.. works for me.

> Still get shell window briefly

python.exe opens a console, you need pythonw.exe

> Your patch didn't have that all of Adib's earlier
> patch

Hmm.. I thought that part was already included. Maybe I looked at trunk

> Didn't put in the pythonw stuff from Adib as I
> couldn't figure out the conflicts.

Open build.xml, search for python.exe and add a similar line for pythonw.exe.

> The conflicts are in the main.cpp file.

It's basically the same code. Use the latest (copy _win32_set_inkscape_env from trunk, call it from main)

[Rygle (rygle)]

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.

I had figured out the build.xml stuff, and got it copying across as but it didn't stop the command window popping up during python operations, so I looked back at Adib's patch here - https://bugs.launchpad.net/inkscape/+bug/187290/comments/13

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.

[Ulferikson (ulferikson)]

> 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.

[theAdib (theadib)]

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

I would like to post Ulfs solution to trunk.

HTH, Adib.

[Ulferikson (ulferikson)]

3.) When the inkscape directory contains spaces, such as "C:\Program Files\", you might need to quote script paths (and the code to unquote it looks broken).

Comment #47, https://bugs.launchpad.net/inkscape/+bug/187290/comments/47, has a patch for this, but it needs more testing to see that it works and doesn't break anything else.

[Rygle (rygle)]

The spawn bug has a patch here - https://bugs.launchpad.net/inkscape/+bug/187290/comments/39
     Albin said he had it working well on Vista SP1 - https://bugs.launchpad.net/inkscape/+bug/187290/comments/41
     I've had it working well on XP SP2 on 0.46 branch
     Ulf has also tested it
     I copied the patch over to the original bug - https://bugs.launchpad.net/inkscape/+bug/204779/comments/19
     The only thing with the spawn bug is when you patch it after the other patches, it complains about a conflict at line 21. You need to keep both options! Very important!

The Environment/Path Patch is here - https://bugs.launchpad.net/inkscape/+bug/187290/comments/30
And that needs a temp file patch - https://bugs.launchpad.net/inkscape/+bug/187290/comments/31
     I've tested that on 0.46 branch no problem

But spaces in the path name require quotes around the path - fix here - https://bugs.launchpad.net/inkscape/+bug/187290/comments/47
    I've also tested this on 0.46 branch no problem

Let's get this baby tested and committed!

[Rygle (rygle)]

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!

[theAdib (theadib)]

As Rygle says FIx is in trunk and patchsets in 0.46 branch. Creating dists for the sf-snapshot section to be reviewed. Adib.

[Ulferikson (ulferikson)]

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?)

[Rygle (rygle)]

Hi Ulf,

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.

[prkos (prkos)]

Im copying from a duplicate bug:

Preben S:
The problem is, that it cannot find python. It aborts after searching for c:\program files\inkscape\C\python.exe.

A workaround that worked for me, was to rename c:\program files\inkscape\python to c:\program files\inkscape\C.

I found out what the problem was using "File Monitor" from SysInternals (now microsoft).

[Marcin Floryan (mfloryan)]

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).

[prkos (prkos)]

For me it works on pre4-2 and also latest build made 31st March (WinXP)

[Rygle (rygle)]

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.

[prkos (prkos)]

The problem appears again in yesterdays build (2nd April) on WinXP, all python related options seem to be affected (effects and help menu).

There are also bugs reported about crashes when saving as .gpl and .dxf and opening .wmf and .cgm that also might be python related: bug 197359, bug 201630.

Program exited with code 03.
(gdb) bt
No stack.

[Alvin Penner (apenner)]

running win32 nightly build Inkscape0804041638.7z

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?

[Rygle (rygle)]

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?

[prkos (prkos)]

I don't know why April2nd didnt work, the official 0.46 and dev build from April 4th do work.

[Marcin Floryan (mfloryan)]

On Sat, Apr 05, 2008 at 07:02:02AM -0000, Rygle wrote:

> 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.

--
Marcin Floryan
http://marcin.floryan.pl/ [GPG Key ID: 0D5581C5]

[Rygle (rygle)]

Moving discussion on the DOS Window to a new bug of its own, so we can leave this one closed.

https://bugs.launchpad.net/inkscape/+bug/215020

[Rygle (rygle)]

Changing to "Fix Released" so Launchpad counts as closed in stats

[Thieric (thieric)]

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.

Is there an executable, easy-to-install patch to fix all this ?

I'm running on Windows XP Media Center Edition.

Thanks a lot

[mahfiaz (mahfiaz)]

No, there is not. But you could try development version out to see if new bugs won't stop you from getting work done.
http://www.inkscape.org/wiki/index.php/InstallHelp#Installing_on_a_Windows_system

[Alvin Penner (apenner)]

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.

[Thieric (thieric)]

No differencies with the last development version, I don't know what to do. A shame, I really needed the 3D edge effect.

[Thieric (thieric)]

Exactly this one :

http://tavmjong.free.fr/INKSCAPE/MANUAL/html_fr/Effects-ModifyPath.html#Effects-Edge3D

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.
>

--
Thiéric RODRIGUEZ
M2 IUP Ingénierie de la Santé,
Management de Projet en Biotechnologies Pharmaceutiques

06-07-89-69-03

[Thieric (thieric)]

Exactly this one :

http://tavmjong.free.fr/INKSCAPE/MANUAL/html_fr/Effects-ModifyPath.html#Effects-Edge3D

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.

[Alvin Penner (apenner)]

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

[Thieric (thieric)]

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.
>

--
Thiéric RODRIGUEZ
M2 IUP Ingénierie de la Santé,
Management de Projet en Biotechnologies Pharmaceutiques

06-07-89-69-03

[jazzynico (jazzynico)]

The bug is back again, on Windows Vista SP1, build 20921.
Works well in 20844.
Any Python related change?

[Alvin Penner (apenner)]

which Effects are you trying to use? I haven't detected any change, running build 20921 on Windows XP.

[jazzynico (jazzynico)]

Not a particular effect. I've try a couple of effects and help menu commands. They all crash the same way.

[jazzynico (jazzynico)]

Yes, it works well on Windows XP.
Vista only bug? I try to confirm with a more recent build asap.

[Alvin Penner (apenner)]

- 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?

[Lawrence (annon0m0s)]

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.

[jazzynico (jazzynico)]

I can test it on 3 computers (XP SP3, Vista SP1, Ubuntu 8.10).

On XP and Ubuntu, everything is alright.

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.

[Alvin Penner (apenner)]

if you are getting this kind of crash, then it is probably worthwhile to try to trap the exit message using the techniques outlined at :
http://kaioa.com/node/42 or http://kaioa.com/node/63

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

[jazzynico (jazzynico)]

I tested with 20932, same problem.
Here's what I get with inkscapec :

-----
C:\Users\Nicolas\Desktop\Inkscape\inkscape20921>inkscapec

(inkscape.exe:4852): Gtk-WARNING **: Impossible de trouver l'ic¶ne ½áedit-select
-allá╗. Le thÞme ½áhicolorá╗
n'a pas non plus ÚtÚ trouvÚ. Peut-Ûtre avez-vous besoin de
l'installer. Vous pouvez obtenir une copie Óá:
        http://icon-theme.freedesktop.org/releases

(inkscape.exe:4852): GLib-CRITICAL **: g_convert: assertion `str != NULL' failed

(inkscape.exe:4852): GLib-GIO-CRITICAL **: g_loadable_icon_load: assertion `G_IS
_LOADABLE_ICON (icon)' failed
** Message: Found local interpreter, 'C:\Users\Nicolas\Desktop\Inkscape\inkscape
20921\python\pythonw.exe', Size: 24576
RegistryTool: Could not set the value 'C:\Users\Nicolas\Desktop\Inkscape\inkscap
e20921\inkscape.exe'
terminate called after throwing an instance of 'Glib::SpawnError'

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.

[Alvin Penner (apenner)]

- did this work previously in Vista?
- 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?

[jazzynico (jazzynico)]

> did this work previously in Vista?

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.

[Alvin Penner (apenner)]

could you try to run Inkscape as an administrator?
if it is a registry access problem, this may affect the behaviour.

[jazzynico (jazzynico)]

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.