© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
> Anyway, what do you think about converting filenames to their
> absolute paths in your official launcher script before changing
> directory?
The legacy packaging for the X11-based Inkscape application bundle on OS X as used for Inkscape 0.91 (and older releases) is a dead end (there will likely be no further official Inkscape packages released based on the current state of the packaging scripts, nor will the current packaging scripts be further maintained).
<opinion>
From my point of view it makes no sense for the project to spend time attempting to add more workarounds for limitations known to be caused by a decision made many years ago about a simplified relocation support in core inkscape for OS X application bundles at the expense of fully supporting regular command line usage with the inkscape binary (configured and compiled with '--enable-osxapp') included in such OS X application bundles.
The fix is to rewrite relocation support (load Inkscape's shared resources relative to the absolute path of the executable itself, like on Windows) or - alternatively - to allow Inkscape to search, find and load its shared resources from XDG locations (which can be changed at runtime via env variables like $XDG_DATA_DIRS) on all supported platforms.
</opinion>
On the other hand the number of reports filed about this issue does indicate that a (custom) launcher script implementing a workaround as proposed (ideally without relying on 'realpath' as additional dependency) would probably be appreciated by a (still small) inkscape user base on OS X (users who don't want to compile / install inkscape via package manager into a fixed prefix, but need to use inkscape via command line nevertheless).
Whoever will tackle packaging of future GTK3-based Inkscape releases (>= 0.93) as self-contained fully relocateble macOS application bundles ought to also rewrite Inkscape's core relocation support for that platform (apart from switching from MacPorts to 'gtk-osx' for the dependencies, and from custom scripts for filling the bundle and the subsequent library path rewriting to 'gtk-mac-bundler' for creating the application bundle itself) - to reach the same level of support as e.g. implemented for Windows and Linux based on the absolute path of the executable itself.
> Another issue: I'd like to suggest changing the error message when
> the file isn't found. "Failed to load the requested file
> somefile.pdf" puts the user much more easily off the track.
>
> I'm not saying this error message is incorrect. It IS correct. But,
> many users would think that there are some problems in the file
> (corrupted image, etc.). The standard message is "somefile.pdf: file
> not found" when the application cannot find the input file.
Messages like these are from core Inkscape (not specific to packaging or platform): if you have suggestions to improve them (across all platforms), please file a separate report (not related to any packaging issues on OS X).