Comment 22 for bug 262617

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" "$@"
---