Issues with inkscape-quartz blueprint

1) AFAICT - in your instructions, you omitted the required step to install the build products locally (./osx-build.sh i).

2) The customized version of 'ige-mac-bundler 0.6.0' seems to have '/opt/local' hardcoded instead of respecting $PREFIX for the dependencies (needs to be fixed upstream in MacPorts):

LeWitt:macosx suv$ port installed ige-mac-bundler
The following ports are currently installed:
  ige-mac-bundler @0.6.0_1 (active)
LeWitt:macosx suv$ ige-mac-bundler Inkscape.bundle
Cannot find source to copy: /opt/local/lib/gtk-2.0/2.10.0

(Note: I decided to test 'ige-mac-bundler' with my current custom MacPorts tree which is installed into a "very-long-path" [1] to be able to use install_name_tool to rewrite the paths of the dylibs).

[1] LeWitt:macosx suv$ which port
/Volumes/green/mp-quartz/with-a-long-long-long-directory-name/bin/port

3) The README file from the source tarbar of 'ige-mac-bundler' says this:
«NOTE: This tool is written to work with a jhbuild built GTK+ , not
Macports. If you build with Macports, make sure that the Pango atsui
module is builtin to the Pango library, by using the configure flag
--with-included-modules=basic-atsui.»

Is this taken care of when installing pango in MacPorts with "+no_x11 +quartz" in $PREFIX/etc/macports/variants.conf or does it require a custom pango portfile?

Sorry - figured out issue 2 (just needed to edit the template 'Inkscape.bundle').

Sorry - issue 3 was apparently also bogus:
LeWitt:macosx suv$ ll Inkscape.app/Contents/Resources/lib/pango/1.6.0/modules/ | grep atsui
-rwxr-xr-x 1 suv staff 17752 Mar 24 17:28 pango-basic-atsui.so*

Got some error messages when running ige-mac-bundler about permissions for libssl.1.0.0.dylib and libcrypto.1.0.0.dylib, but similiar errors also occurred with the current bundling script, mentioned in bug #532765 and addressed in the current osx-app.sh script (r9170).

The app (r10124) launches fine, initial notes:
- as far as I can tell all libraries are loaded from within the application bundle
- no extension support for now (module lxml missing)

4) Launching Inkscape.app, it complains about

/Volumes/green/mp-quartz/bin/Inkscape-quartz.app/Contents/MacOS/Inkscape: line 106: test: too many arguments

The contents of $LC in line 106 with my current language settings:
/usr/share/locale/en_AU.UTF-8
/usr/share/locale/en_CA.UTF-8
/usr/share/locale/en_GB.UTF-8
/usr/share/locale/en_IE.UTF-8
/usr/share/locale/en_NZ.UTF-8
/usr/share/locale/en_US.UTF-8

5) If I rename the MacPorts tree as well as the Inkscape source tree and launch Inkscape.app, it complains about

Fontconfig error: Cannot load default config file

and later crashes when e.g. opening the 'Text & Font' dialog.

6) The default launcher script from ige-mac-bundler exports

export DYLD_LIBRARY_PATH="$bundle_lib"

This had caused various issues before with the packaged Inkscape application on OS X, and the main reason for using the install_name_tool at all in the current packaging scripts was to avoid setting this variable. Is it really required here? As far as I can tell, the app loads the linked dylibs from within the application package fine without it…

1) Fixed in blueprint
2) Yes, it's in Inkscape.bundle. Added note to related bug.
3) Same for me.
4) I don't have that kind of error, can you provide more than just $LC?
5) Will be fixed soon with a new patch in https://bugs.launchpad.net/inkscape/+bug/738947
6) I should ask jralls about the initial reason, but removing it seems OK. See sme new patch in same bug report.

7) permissions error with 'Contents/MacOS/Inkscape' from v2:
Version 2 of 'patch-ige-mac-bundler.diff' adds
   packaging/macosx/launcher.sh
but doesn't set its permissions as 'executable'. The file is copied into the application package, but permission to execute is denied and Inkscape.app fails to launch:

([0x0-0x15c25c1].com.apple.myCarbonNibApp[7538]) posix_spawnp("/Volumes/green/mp-quartz/bin/Inkscape-quartz-v2-r10128.app/Contents/MacOS/Inkscape", ...): Permission denied

Inkscape.app launches ok after changing the permissions:
$ chmod 755 "Inkscape.app/Contents/MacOS/Inkscape"

8) Inkscape's translation files from 'src/Build/share/locale' are not included in the application package.

Also requires
   export INKSCAPE_LOCALEDIR="$bundle_res/locale"
in the launcher script or in the optional 'Contents/Resources/environment.sh' file. The path for $INKSCAPE_LOCALEDIR may vary - above example uses the same location as 'osx-app.sh'.

9) Extensions

As a workaround for now to test python-based extensions, I have prepended MacPorts' bin directory and "$bundle_contents/MacOS" to $PATH in 'Resources/environment.sh'. Basic extensions work fine (using the python modules installed with MacPorts), however there is a problem with extensions like 'Extensions > Arrange > Restack' which call inkscape on the command line to query objects. These extensions fail because of the capitalisation done by the ige-mac-bundler script (in the package created with osx-app.sh, the launcher script in 'Contents/Resources/bin' is called "inkscape" and thus is found and spawned by the extension script).

As a point in the wishlist, I'd really love to see that the command line features are included. It's very convenient to have the SVG files in a directory and then have a Makefile to convert them to eps (for latex) or pdf (for pdflatex) when you are using Inkscape to produce the figures for longer manuscripts in a LaTex environment:

%.pdf: %.svg
     inkscape -D -A $< $@

%.eps: %.svg
     inkscape -D -E $< $@

is always present in my LATeX environments ;-) And this command doesn't fire up the GUI and is therefore quite
fast.

@Paaguti-hotmail and others - for requesting features, please use bug #738947. This report is about actual issues running the packaged version following the instructions in the blueprint.

10) missing modules in the application bundle:

The gnome-vfs module '$PREFIX/lib/gnome-vfs-2.0/modules/libfile.so' gets loaded from the MacPorts tree (if present) as soon as the file dialog is used to e.g. open a file from disk.

(The currently used packaging script does include the gnome-vfs modules in the application bundle:
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/head:/packaging/macosx/osx-app.sh#L343>, details on line 345)

"export bitmap" dialog takes very long (40s on a 1350MHz G4) to open with a file with apx. 900 items. The time required seems to be proportional to the number of objects in the file (200 objects require 10s of dialog box opening time).

Could this be related to
https://bugs.launchpad.net/inkscape/+bug/442835 ?
(file selection very slow, even if "file preview" is disabled)

@Wolf - did you compare the performance opening the 'Export bitmap…' dialog with the same file, using the same revisions/versions of Inkscape built with the Quartz and X11 backend?

IMHO you describe the same issue as
Bug #719993 “RENDERING_BBOX calculation blocks Inkscape if export dialog is kept open”
which is not related to the backend of GTK+ or the GtkFileChooser widget.

(attaching a simple test file with 900 paths: the 'Export Bitmap…' dialog opens immediately with both X11 and Quartz backend builds of r10255. The dialog opens quickly due to the low complexity of the objects.
Filter effects, blurs and stroked paths with a huge number of nodes take much longer for the calculation the precise bbox for export. With the test file I mentioned in bug #719993, both quartz and X11 builds of current trunk take > 60 seconds on my system to open the 'Export bitmap…' dialog.)

The app built alongside the instructions in the blueprint seems not to launch if xcode tools are not installed. I had to reinstall my system recently - and inkscape aqua wont launch anymore till I reinstalled xcode tools 3.1.3. There were no really interesting console messages - so it may be wise to check ports, files and libraries called by inkscape.

> The app built alongside the instructions in the blueprint

Before creating the application bundle, did you really rebuilt MacPorts completely with the LDFLAGS 'headerpad_max_install_names' (or alternatively make a custom install of MacPorts with a long-long directory path as required for the current packaging scripts) - both methods to allow to rewrite the install paths of the linked/shared dylibs inside the application bundle? Or did you rely on setting 'DYLD_LIBRARY_PATH' in the launcher script?

> and inkscape aqua wont launch anymore till I reinstalled xcode tools 3.1.3.

More details and paths of the missing binaries/libs would be of help:
1) Launch your current Inkscape-quartz.app after reinstalling Xcode 3.1.3
2) open 'Applications > Utilities > Activity Monitor', select the process 'inkscape-bin'
3) 'Cmd+I' (Get Info) on the process and switch to 'Open Files and Ports'
4) copy and paste the list of files into a new TextEdit document, save as Plain Text file and attach it here.

Attaching a list of system files loaded from outside the application bundle (tested with official Inkscape 0.48.1 (GTK+/X11), r10124, 10145 and r10166 (GTK+/Quartz) bundled as described in the blueprint. AFAICT there is nothing in this list that specifically belongs to the Xcode tools (but I might be wrong).

System:
- Mac OS X 10.5.8 (i386)
- Xcode 3.1.4
- MacPorts 1.9.2 (custom long prefix)
- patched ige-mac-bundler (trac #27794)

(I don't have a recent revision of trunk built according to the blueprint ATM, as it is easier to test new commits with the command line version, linked into a "pseudo" application bundle).

> and inkscape aqua wont launch anymore (…)
> There were no really interesting console messages

Does it create a crash report? Please attach if still available in '~/Library/Logs/CrashReporter'.

test build with r11623 from lp:~inkscape.dev/inkscape/dev-osx on OS X 10.7.4:

1) The proposed solution for python extensions can't work (same issue was encountered with old launcher…)

The install_names of the two *.so libs from lxml are changed to be relative to the executable of the app bundle. The extensions however launch a separate binary (/usr/bin/python) which can't find the required libraries since '@executable_path/../Resources/lib' no is relative to the path of the python binary.

AFAIU either you need to include a copy of a python installation (or a virtualenv (?)) into the app bundle, or build and link the required lxml module statically using the system python version (and not the one from MacPorts), and not run install_name_tool on its *.so libs.
('osx-lxml.sh' script in my branch compiles the python module for the system python (without any references to MacPorts), installs lxml directly into the app bundle skeleton and then only needs to be copied along with the rest into the final app bundle).

Apart from that $PYTHONPATH from environment.sh doesn't match the dest path set in Inkscape.bundle.

2) gdk-pixbuf loaders don't work for me at all (and AFAICT none of the other gtk modules, including theme engines, either) - probably because I haven't yet rebuilt gtk2 configured with '--enable-quartz-relocation' (because my other builds used to test trunk are regular builds, not bundled as osxapp).

3) ige-mac-bundler: I used a custom port for latest gtk-mac-bundler 0.6.1 instead (with parts of the old patches).

Correction:
> 2) gdk-pixbuf loaders don't work for me at all (and AFAICT none of the
> other gtk modules, including theme engines, either) - probably because I
> haven't yet rebuilt gtk2 configured with '--enable-quartz-relocation'
> (because my other builds used to test trunk are regular builds, not
> bundled as osxapp).

Theme engines are actually loaded (depending on gtkrc file used by the app bundle) - the gdk-pixbuf loader failure must be caused by something else…

On 26/08/2012 06:59, ~suv wrote:
> 3) ige-mac-bundler: I used a custom port for latest gtk-mac-bundler
> 0.6.1 instead (with parts of the old patches).

@gellule - do you see any obvious mistakes in the custom portfile for
gtk-mac-bundler 0.6.1 and/or in the patch files used (see attached)?

@~suv

Wrt https://bugs.launchpad.net/inkscape/+bug/738973/comments/21

I updated $PYTHONPATH with rev. 11624 in https://bugs.launchpad.net/+branch/~inkscape.dev/inkscape/dev-osx to and its seems that things are working for me (with mmy macports installatioj out of the way). Could you please check one more time?

By the way, I am getting a little lost with all the great feedback you're giving me. Could we open bug reports and somehow tag them so that they can be easily searched for? I can have a first pass at this if you wish.

-Gellule

@~suv

Wrt https://bugs.launchpad.net/inkscape/+bug/738973/comments/23

Looks good to me. Especially the use of chmod to deal with some of the crypto libraries that macports keeps read-only.
The first part of the "bundler.py" patch is not needed, is pango is built with +builtin_modules. I personally wasn't able to make it work without that variant, even with the first part of the patch.

Do you, or somebody else from inkscape, have commit rights in macports? It would be nice to have it there, ready to go.

-Gellule

On 27/08/2012 20:49, Gellule wrote:
> By the way, I am getting a little lost with all the great feedback you're giving me.
> Could we open bug reports and somehow tag them so that they can be easily
> searched for? I can have a first pass at this if you wish.

Proposal: I will file new reports for issues as they occur with local packages based on the renewed blueprint, and tag them with 'gtk-osx' and 'packaging'. You can then search for them via 'Advanced Search' <https://bugs.launchpad.net/inkscape/+bugs?advanced=1>:
1) Scroll down on that page to 'Tags:',
2) enter both tags into the field,
3) check '[x] All' right below the 'Tags:' field
   (to only find reports which have both tags set)

We had used the tag 'gtk-osx' for all issues specific to build and runtime issues if Inkscape is built with the Quartz backend of GTK+ (irrespective of whether mac menu integration was used or not). Several of these reports are placeholders of upstream issues. The name 'gtk-osx' wasn't a good choice (now I know better and would have used 'gtk-quartz' instead), but at that time I was too focused to not have 'Aqua' sneak in into the tags ;) Changing all tags now doesn't make sense IMHO.

We could use a combination of tags for separate issues:
'gtk-osx' -> general category for issues with Inkscape using the Quartz backend of GTK+
'gtk-osx packaging' -> issues with application bundles created with gtk-mac-bundler
'gtk-osx desktop-integration' -> (future) issues with 'gtk-mac-integration / gtk-osx-application'

On 27/08/2012 21:10, Gellule wrote:
> Do you, or somebody else from inkscape, have commit rights in macports?

AFAIK no.

Attaching an updated version of the port file, which adds the same
variant as pango has (for now, it only deletes the patch for pangorc).

I also fixed rewriting the python include path in the launcher stub
installed by the port.

Follow-up report filed for issues running python-based extensions:
Bug #1042597 “[inkscape-quartz] extensions fail with 'Symbol not found: _exsltDateXpathCtxtRegister'”
<https://bugs.launchpad.net/inkscape/+bug/1042597>

Re: gdk-pixbuf errors
Figured out the gdk-pixbuf issue - AFAICT "${prefix}/share/mime" was missing from the app bundle. Will attach diff to new report later.

Re: gdk-pixbuf errors
Good catch ~suv!
http://bazaar.launchpad.net/~inkscape.dev/inkscape/dev-osx/revision/11627

I've also added gtk-mac-integration support to that same branch. Let me know how it works for you. Some of the issues reported on Roy Liu's patch in https://bugs.launchpad.net/inkscape/+bug/721448 have been fixed.

Follow-up report filed for issues with gtk-mac-integration (global menu bar):
Bug #1043266 “[inkscape-quartz] gtk-mac-integration support”
<https://bugs.launchpad.net/inkscape/+bug/1043266>

Follow-up report filed for issues with gtk-mac-bundler (paths, included deps and data):
Bug #1043279 “[inkscape-quartz] gtk-mac-bundler issues”
<https://bugs.launchpad.net/inkscape/+bug/1043279>

Switching the build system to use upstream 'gtk-mac-bundler' instead of the custom 'osx-app.sh' script for GTK+/Quartz-based packages is currently no longer being actively worked on (might still be investigated as option for future Quartz-based packages).

Closing - out-of-date (the report was based on the branch 'osx-dev' which hasn't seen any activity in the past years).

Bug #738947 tracks the proposal to use gtk-mac-bundler for packaging (GTK+/Quartz based builds only).