Edit externally doesn't work on Windows

[capnhud]

When trying to edit a bitmap image with development snapshot Inkscape19754-0808281147.7z on Windows XP SP3 I receive in the status bar the following message

Failed to execute helper program (invalid argument).

In the inkscape preferences the editor selected is gimp.

[capnhud (render1232)]

Maybe an addition to add a dropdown box so that in inkscape preferences I could navigate directly to gimp.exe would solve the problem. In scribus gimp is also listed but I have to navigate to the execution file itself in order to make this similar operation take place. Maybe it is the same in this situation also. Just the name itself is not working even in the current dev versions.

[capnhud (render1232)]

Will this be fixed in time for .47? In the windows builds the call must be to gimp.exe and not just gimp.

[Guillermo Espertino (Gez) (gespertino-gmail)]

Confirmed. It's a bug since the options are showed in the UI but they have no effect.
If the operation is not suported in Windows, the users of that OS shouldn't have the option in the UI. Of course a custom path input that let them point to a bitmap manipulation program executable would make them happier than a hidden command ;-)

[Alvin Penner (apenner)]

- in Windows XP the default editor is mspaint.exe.
- in the directory C:\Windows\System32 or %SystemRoot%\System32\mspaint.exe
- perhaps this could be added as an option in the dropdown box.

[capnhud (render1232)]

Is it not possible just to be able to browse to the program itself? It would be nice to integrate gimp or whatever graphic editor of choice with inkscape

[theAdib (theadib)]

capnhud, could you do a screenshot of scribus. How they solved it there. Thx, Adib.

[capnhud (render1232)]

I hope this is what you are referring to.

[Pablo Trabajos (pajarico)]

The user should be able to specify any path (and arguments). The current method does not only not work on Windows, but it doesn't let me use Photoshop either (or any other software apart from the narrow selection on the drop-down menu).

Please fix it.

[capnhud (render1232)]

Will this get fixed for the .47 release?

[Jan Bartsch (bartschj)]

Do you work on a fix for the next versions?
Or is the bug not prioritized or not removable?

Greetz from Germany
Jan

[jazzynico (jazzynico)]

This bug can be fixed only if someone with appropriate knowledge (maybe you?) decides to.
Unfortunately, nobody's currently working on it AFAIK.

[jazzynico (jazzynico)]

Just found a workaround:
1. Open you preference file (C:\Documents and Settings\%USERNAME%\Application Data\Inkscape\preferences.xml).
2. Search "bitmapeditor".
3. Remove replace the choices attribute value with the full path of your favorite bitmap editor (successfully tested with choices="C:\Program Files\GIMP-2.0\bin\gimp-2.6.exe").

[jazzynico (jazzynico)]

Ok, I'll try to take a look.

[Jan Bartsch (bartschj)]

"This bug can be fixed only if someone with appropriate knowledge (maybe you?) decides to."
I'm sorry, but my knowledge above Inkscape is not "appropriate" yet ;)

Amazing! Thank you! :)

This is working with linked bitmaps? But not with embedded?
Do you have the same problem? Or is this intended?

[jazzynico (jazzynico)]

> This is working with linked bitmaps? But not with embedded?

Since the the context menu entry is grayed out and that editing an embedded bitmap outside Inkscape probably is a bit tricky, I'd say it's intended.

[jazzynico (jazzynico)]

First try attached.
I've reused the open dialog code, and customized it so that it doesn't show the preview pane and image filters.
Tested on Windows XP and Ubuntu 10.10, trunk revision 10042.

Please test and comment (save your existing preferences.xml file first!).

[su_v (suv-lp)]

@JazzyNico - I tested your patch on osx too - since as far as I understand, the new code is seen by all platforms and allows to select the external editor by full path not only on Windows. If this testing doesn't help at the moment and interferes with solving the issue for the Windows port in the first place, please do tell me.

With this patch - tested with r10045 on OS X (built as normal linux command line app, not as osxapp) - Inkscape opens a linked image for external editing always in Gimp, no matter what I choose in the dialog or which path is stored in the preferences file (tested with default (new) preferences). How can I debug what is happening? Or is this intended?

For the osxapp-enabled and packaged version, we'll probably have different needs for the dialog (or add special instructions for normal Mac users once Inkscape actually calls the executable (binary or shell script) selected in the dialog). Probably I should open a separate report for the issue on OS X? Would it be possible to enter a command string (with arguments) instead of choosing an executable itself?

Example to launch an normal application on Mac OS X from the command line:
  $ open -a Gimp filename.jpg
or
  $ open -a Pixen "ripple_100 copy.png"

Inkscape packaged for Mac OS X already uses a similar command string for the print preview launched from the print dialog (GTK settings default to evince which is not available on osx):

522 # use OS X default pdf-viewer for print preview
523 gtk-print-preview-command="/usr/bin/open %f"

<http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/head:/packaging/macosx/Resources/themes/Clearlooks-Quicksilver-OSX/gtk-2.0/pre_gtkrc#L522>

[jazzynico (jazzynico)]

@suv - Thanks for your tests.

> the new code is seen by all platforms and allows to select the external editor by full path not only on Windows

Yes, I didn't wanted to implement a workaround for Windows users only, and found it more elegant to use a file selector on Gnu/Linux and OSX too.

> Inkscape opens a linked image for external editing always in Gimp

My fault. I forgot to add a context menu modification in the diff... I'll send a new patch later today. For your information, the gimp fall-back is hard-coded in ui\context-menu.cpp, in case no editor is selected. It could be improved by checking the existence of the selected editor (todo...).

> Would it be possible to enter a command string (with arguments) instead of choosing an executable itself?

It doesn't work currently (the launcher doesn't parse the command line, and just throws two arguments: the path and the bitmap file), but it would be an improvement on all systems. And I guess solving it would probably solve the OSX "open" command issue. While I'm at it, I can take a look...

[jazzynico (jazzynico)]

New patch, with corrected context menu code.

[jazzynico (jazzynico)]

Now with command line options support.
Tested on Ubuntu 10.10 and Windows XP, Inkscape 10050.

@~suv - Could you please test the "open" command with this new patch?

[jazzynico (jazzynico)]

Precision: limited command line support; the image is always added at the end, after the bitmap editor path (no %f support).

[su_v (suv-lp)]

Oops - you have been faster than me: while you worked on the third version of the patch I tested the second one, here my findings anyway (tested with r10053, built as normal unix-style application, no tests yet with the bundled version):

From the applications I tested [1] [2], it seems that only Gimp handles the URI well, others apparently don't handle the URL encoding properly or just can't find the image file.
The string passed from Inkscape to the application [3] - based on 2 default linked bitmap images with absolute path ref:
 "file:///Volumes/blue/img/Inkscape/test/bug/ripple_100%20copy.png"
 "file:///Volumes/blue/img/Inkscape/test/bug/ripple_100.png"

[1] unix-style apps (command line binary or script expecting a file name):
- MyPaint (first image fails, second image opens ok),
- mtPaint (both images fail to open)

[2] osx-bundled apps (those apps are in fact a directory structure hidden for normal users, but visible in e.g. a GtkFileBrowser. A user can run such an app by calling a certain binary or launcher inside the structure [Contens/MacOs/{appname}]):
- Pixen (no file opened)
- Paintbrush (segfaults in both cases).

[3] Tested by inserting 'echo "$@"' into the shell script wrapper used for MyPaint:
---
#!/bin/bash

export GTK2_RC_FILES="$HOME/.gtkrc-2.0.mypaint"

export PATH="/Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin:$PATH"
echo "launching MyPaint from Inkscape..."
echo "/Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/mypaint" "$@"
exec "/Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/mypaint" "$@"
---

[su_v (suv-lp)]

Additionally tested with 'display' from ImageMagick: like MyPaint, it fails to load the image with the space in the file name:

display: unable to open image `/Volumes/blue/img/Inkscape/test/bug/ripple_100%20copy.png': No such file or directory @ error/blob.c/OpenBlob/2584.
display: unable to open file `/Volumes/blue/img/Inkscape/test/bug/ripple_100%20copy.png' @ error/png.c/ReadPNGImage/3083.
display: no data returned `file:///Volumes/blue/img/Inkscape/test/bug/ripple_100%20copy.png' @ error/url.c/ReadURLImage/229.

The other one displays without error.

[jazzynico (jazzynico)]

> From the applications I tested [1] [2], it seems that only Gimp handles the URI well, others apparently don't handle the URL encoding properly or just can't find the image file.

Confirmed on Ubuntu 10.10. Works correctly with Gimp, Evince and Krita, but not with myPaint and ImageMagick's display command. Unfortunately, that bug doesn't seem to come from a recent change (I didn't modify the href handling stuff), and thus I'll have to investigate again...

Apart from this URL issue, could you confirm that "open -a Gimp" style commands now work (at least with "absolute with no zero" paths).

[jazzynico (jazzynico)]

To be sure, is that URL issue a regression (does it work correctly with the trunk version when you select mtpaint in the list)?

[su_v (suv-lp)]

It's not a regression - I can confirm it for Inkscape 0.48.1 (unix-style command line app), with mtPaint, MyPaint and display (having added MyPaint and display to the list of editors in preferences.xml). Sorry for not thoroughly testing this (I haven't used this feature extensively so far - mainly to test if and how it could possibly work with the 'GIMP on OS X' application bundle).

Does it work for you with applications other than Gimp on Ubuntu and Windows, e.g. with display from ImageMagick?

[su_v (suv-lp)]

patch v3 tested with r10053, built as normal unix-style application, no tests yet with the bundled version:

> could you confirm that "open -a Gimp" style commands now work

Yes, works with Gimp as well as with other applications like Pixen or Paintbrush. Both images I previously tested can be opened and edited externally, and reload automatically in Inkscape after saving.

It even works to just have "open" as command string - this will open the image in the associated default application on the current system (for me it loads the PNG file in Apple's 'Preview.app' - a universal viewer for image formats, PDF and PostScript files with some minimal editing functions (e.g. to crop, resize, flip or rotate, adjust color and add/edit the color profile).

With 'Gimp on OS X', there are some caveats I need to clarify independently of your changes - whether it works with the unedited application as downloaded and installed from sf.net (at the moment I use it with a custom environment in the launcher scripts).

The command line applications mtpaint, display and mypaint still show the same issues with handling the file URI.

[su_v (suv-lp)]

Correction:
Not all applications called with 'open' seem to handle the URL-encoded spaced well (I was wrong e.g. about Preview.app).

Further tests on Mac OS X 10.5.8 Leopard (i386):

a) Inkscape built and run as unix-style command line app
works fine with 'Gimp on OS X' 2.6.11 newly installed and started out-of-the-box with new preferences.

b) Inkscape built, packaged and run as osxapp:
Applications like Pixen, Paintbrush or Preview launch the same way as with the command line version (called with "open -a {app-name}"). However, there are interferences in the shell environment inherited by the spawned process from Inkscape which cause interaction with e.g. 'Gimp on OS X' to fail (because the two application use too different packaging strategies and not fully compatible bundled library versions), as well as with MyPaint (pyGtk) and possible other GTK+ applications.

If a wrapper script for the external application unsets these environment variables (set by the inner launcher script of Inkscape.app), the external editor works also with the osx-packaged Inkscape version:

#unset PYTHONHOME
unset PYTHONPATH
unset DYLD_LIBRARY_PATH
unset FONTCONFIG_PATH
unset PANGO_RC_FILE
unset GTK_IM_MODULE_FILE
unset GDK_PIXBUF_MODULE_FILE
unset GTK_DATA_PREFIX
unset GTK_EXE_PREFIX
unset GNOME_VFS_MODULE_CONFIG_PATH
unset GNOME_VFS_MODULE_PATH
unset XDG_DATA_DIRS
unset ASPELL_CONF

Not sure how this could be addressed - maybe better discussed in a separate report.

[su_v (suv-lp)]

From my POV this last version works well - whether and how well the file URI is handled or not seems to depend on the called application itself and outside of Inkscape's scope:

- Not all external image manipulation applications seem to handle the file URI - possibly depending on how they have been coded or configured (MyPaint, display, mtPaint)?
- On OS X, the system command '/usr/bin/open' [1] handles the URI (including spaces and umlauts) correctly and the called OS X application can find the correct file (I was mistaken in my last "correction").
- On OS X, the interference of the GTK+ environment (and related dependencies) when calling external applications from an osxapp-enabled and packaged Inkscape needs to be solved elsewhere (packaging-related issue).
- Are some safety checks or restrictions needed, related to the command string? Or is it entirely up to the user not to test any variations of 'rm -rf /'? ;)

[1] <http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/open.1.html><

[su_v (suv-lp)]

typo - correct link:
[1] <http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/open.1.html>

[jazzynico (jazzynico)]

> Does it work for you with applications other than Gimp on Ubuntu and Windows, e.g. with display from ImageMagick?

Yes, it works on Windows with Firefox, IE8 (as viewers), but not with mspaint and (but not due to URI parsing problems) display.
I've also tested on Ubuntu, and it works correctly with krita and evince, but not with mypaint and display.

> Not all external image manipulation applications seem to handle the file URI.

That's the key issue. Converting the xlink:href value from URI to IRI (eg "file:///C:/Documents%20and%20Settings/nicolas/Bureau/trex.png" to "C:\Documents and Settings\nicolas\Bureau\test.png") seems to work as expected with mspaint on Windows XP, and with mypaint and display on Ubuntu (Gimp still works in both cases).
Thus using a conversion code in Inkscape when we have an URI (the href must then be enclosed in single quotes to be parsed correctly) should work.

BTW, according to the SVG1.1 reference (http://www.w3.org/TR/SVG/linking.html#IRIReference), IRIs are used in xlink:href attributes. Thus Inkscape now *should* use IRIs here. But since the previous versions of the same reference mentioned URIs, and not IRIs, I guess we must also support it...

[jazzynico (jazzynico)]

> However, there are interferences in the shell environment inherited by the spawned process from Inkscape...

I've just encountered the same bug on Windows XP. Launching Gimp 2.6.10 from Inkscape generate libgtk errors. Updating Gimp to 2.6.11 solve the issue. I guess we have to be careful when updating our devlibs and make sure we use the same as Gimp (or find a workaround).

[jazzynico (jazzynico)]

New patch which addresses the URI vs IRI bug. URIs (starting with file:) are now converted to IRI (filenames) and the resulting path is enclosed with single quotes in order to prevent the parser from splitting the href on white spaces.

Two remaining bugs (at least) need to be solved before committing:
1. Manually modified path are not taken into account when clicking the browse button (the dialog path is set to the last path selected with the dialog) [affects the gtk dialog].
2. Inkscape sometimes crashes when opening the dialog on Windows.

@~suv - Do you still have one of my very first patches (the first or second)? I'm quite sure bug #2 is relatively recent, but unfortunately I didn't keep my old diff files (I did all my recent Windows tests with a gtk dialog and thus discovered the bug just after switching back to the native dialog)...

[su_v (suv-lp)]

> New patch which addresses the URI vs IRI bug. URIs (starting with file:)
> are now converted to IRI (filenames) and the resulting path is enclosed
> with single quotes in order to prevent the parser from splitting the
> href on white spaces.

Tested with default and 'osxapp-enabled' 0.48+devel r10057 on OS X 10.5.8 (i386): no regressions found so far.
All previously tested external applications (gimp, mtpaint, mypaint, display, open (using Preview.app, Pixen.app, Paintbrush.app)) can open and edit files with spaces or umlauts in the file name.

[jazzynico (jazzynico)]

@~suv - Thanks for the files. The Windows bug is now fixed. It was already present in the first patches, but didn't happen every time (a stupid memory allocation issue...).

I think I'll leave the issue #1 in comment #33 because it's a bit tricky to fix it on the native Windows dialog. It would need to attach the dialog to the GTK preferences dialog and I'm not sure it's feasible (other native dialogs are attached to the main window, see the image selection in the filter editor, image filter effect).
There's a remaining issue with the native dialog (the preview is closed when you open the bitmap editor selector first), but a fix is in progress.

[jazzynico (jazzynico)]

Fix committed in the trunk, revision 10062.