Use ige-mac-bundler to package the GTK/Quartz version of Inkscape for OSX

This patch, adds into packging/macosx two files:
Inkscape.bundle, to be called by ige-mac-integration to generate Inkscape.app.
Info.plist, needed by the operation above, different from Info.plist found in packaging/macosx/Resources

Notes:
You can get ige-mac-bundle from MacPorts
You need a custom version, as described there: https://trac.macports.org/ticket/27794

As of now, if you follow https://trac.macports.org/ticket/27794#comment:5, you should be fine.

> Discussion on the use of ige-mac-bundler is here.

- Could you give some details _why_ changing to ige-mac-bundle would be better than the current solution? The blueprint also gives no reasons, only instructions. It will require to completely rebuild (or create a new) MacPorts tree - to build all dependencies with "-Xlinker -headerpad_max_install_names"). A custom MacPorts installation is already needed for the current packaging script *if* one wants to avoid using DYLD_LIBRARY_PATH. I'd be interested in some rationale and advantages of ige-mac-bundler before starting to build yet another MacPorts tree to figure out myself (I have no real need for yet another set of the full boost libraries ;) Luckily building 'atlas' can be turned off as global variant, like apache).

- How will bundling of the basic python modules work? On Leopard, numpy is not installed by Apple, nor is lxml.

- How easy will be creating Universal packages?

- Will it require Snow Leopard?

-Why ige-mac-bundle?
The main reason for suggesting this approach is that it lowers the amount of code to be maintained under Inkscape (to the risk of increasing its dependency on others). In the longer term, jhbuild could be used instead of MacPorts. In my case, I already need a MacPorts tree. Maybe using the tools that others have developed for the very purpose of integrating GTK+ application with OS X is a valid reason. Before that, and hopefully, something good will come from the -headerpad_max_install_names discussion at MacPorts, so that the custom MacPorts step is not needed anymore.

-Python?
I imagine python can be built under MacPorts and then included by ige-mac-bundler. What to include in the app can be fine tuned by ige-mac-bundler.

-Universal packages?
That I don't quite know. It looks like a build per arch might be needed. GnuCash provides packages that way, using ige-mac-bundler.

-Snow Leopard requirement?
No requirement for the ige-mac-bundler part. For ige-mac-integration, some aspects are x86_64, some are not.

By the way, I have started experimenting with the menu bar integration provided by ige-mac-integration. It looks like Inkscape does not use GtkUIManager for its menus. It seems to be an issue.

WARNING: patch-ige-mac-bundler.diff assumes that you have macports installed in /opt/local. If not, modify Inkscape.bundle accordingly.

Please consider attached change to Info.plist:

Symptom: When using a tool that constantly updates the message in the status bar (shape tools, pen tool, select tool when transforming), the updates on-canvas are delayed until mouse movement stops (i.e. no more updates of messages to the notification area). This causes a visible lag when e.g. rotating or stretch an object, or drawing a new path with the pen (bézier) tool.

Proposed fix: Not sure if it is a proper solution (Apple describes it as "A last resort"), but after disabling coalesced updates as described in 'Technical Note TN2133' [1] the lag of redraws on-canvas described above no longer occurs (tested with r10124 on OS X 10.5.8 (i386), gtk2 @2.24.3_0+no_x11+quartz).

Please review and test.

[1] <http://developer.apple.com/library/mac/#technotes/tn2133/_index.html>

Symptom: launching Inkscape on a system without having launchd automatically set $DISPLAY for X11/Xquartz fails (see bug #251982):

LeWitt:bin suv$ unset DISPLAY
LeWitt:bin suv$ ./Inkscape-quartz-v2-r10128.app/Contents/MacOS/Inkscape
./Inkscape-quartz-v2-r10128.app/Contents/MacOS/Inkscape: line 108: test: too many arguments
Nothing to do!
LeWitt:bin suv$

Proposed workaround (if considered relevant, and until this is fixed - if ever - in Inkscape itself): add the extra argument
EXTRA_ARGS="--with-gui"
in the launcher script itself or in 'Resources/environment.sh'.

Note: above workaround may conflict with extension scripts which call inkscape themselves to query objects (see comment #10 in bug #738973).

a) Recent port of AbiWord to Mac OS X has committed a patch to the MacPorts pango port [1] to optionally build pango with included modules (AFAIU it no more requires setting up 'pangorc' and 'pango.modules' with adapted paths inside the application bundle). Maybe worth while to be considered for bundling pango with Inkscape, too (for both the current X11 based bundle as well as Quartz based ones)?

b) To be investigated: for the port of AbiWord (AFAIU pure Cocoa, no GTK+) support for AppleSpell was added/fixed for enchant [2] - possibly could be useful to improve/fix Inkscape's built-in spellchecker command (bug #396322)?

[1] <https://trac.macports.org/ticket/12735>
[2] <http://thread.gmane.org/gmane.os.apple.macports.devel/14810>
    <http://thread.gmane.org/gmane.os.apple.macports.devel/14815>

Closing given native macOS Inkscape 1.0 makes this report obsolete. If there are issue with the native release, please check here to see if it has been reported: https://inkscape.org/inbox. Thank you!

Closed by: https://gitlab.com/Qantas94Heavy