Better integration with Mac OS X OS

Bug #1097009 reported by Valerio Aimale on 2013-01-07
This bug affects 2 people
Affects Status Importance Assigned to Milestone

Bug Description

A start for a better integration with Mac OS X OS

Valerio Aimale (valerioa) wrote :

Perform all the steps in

[unless they have been merged in the trunk]


git clone

cd gtk-mac-integration
patch -p1 < gtk-mac-integration-valerio.patch
./configure --prefix=/opt/local/macports-with-a-very-looooooooooooooooooooooooooong-name/
make install
cd ..

cd <inkscape source dir>
patch -p1 < 0.48.x-valerio-osx-integration.patch
cd packaging/macosx
LIBPREFIX=/opt/local/macports-with-a-very-looooooooooooooooooooooooooong-name/ ./ a c b i p -py /opt/local/macports-with-a-very-looooooooooooooooooooooooooong-name/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/
LIBPREFIX=/opt/local/macports-with-a-very-looooooooooooooooooooooooooong-name/ ./ d

Valerio Aimale (valerioa) wrote :
Valerio Aimale (valerioa) wrote :
su_v (suv-lp) on 2013-01-09
tags: added: desktop-integration gtk-osx packaging
su_v (suv-lp) wrote :

1) New dependencies
> git clone
> ./configure --prefix=/opt/local/macports-with-a-very-looooooooooooooooooooooooooong-name/

Does building with the changes from '0.48.x-valerio-osx-integration.patch' require the latest git version of gtk-mac-integration or is an older port already installed (based on the Portfile for v1.0.1 [1]) sufficient? Or phrased differently: you don't happen to have a current portfile available which would allow to install gtk-mac-integration from git as regular port? (Installing from external sources directly into a MacPorts prefix might be feasible if one has a dedicated MacPorts tree used once to compile and bundle a specific Inkscape package - otherwise it is not really an option (IMHO)).

2) Configure checks, GTK+ backend
> -inkscape_LDFLAGS = --export-dynamic $(kdeldflags) $(mwindows)
> +macosx_sources = osx-integration.cpp osx-integration.h
> +inkscape_LDFLAGS = --export-dynamic $(kdeldflags) $(mwindows) -lgtkmacintegration
> +#ifdef __APPLE__
> +#include "osx-integration.h"
> +#endif /* __APPLE__ */

As far as I understand, the patch '0.48.x-valerio-osx-integration.patch' assumes that building Inkscape on OS X is done (unconditionally) with the Quartz backend of GTK+ (checking only for PLATFORM_OSX and __APPLE__), and will likely fail otherwise (since gtk-mac-integration is not available for the X11 backend)? Would it be possible to add more specific checks for the GTK+ backend and the availability of gtk-mac-integration to continue supporting builds with either backend, similar to the tests and checks used in this branch [2]?

[1] <>
[2] <>

su_v (suv-lp) wrote :

Attaching updated MacPorts portfile for gtk-mac-integration 2.0.1 (port name: gtk-osx-application), to a large extent based on

- new variants for gtk+ version
- remove patch for gtkosxapplication.h (fixed upstream)

Use variant +gtk2 to avoid building against GTK3 (automatically detected by configure and linked to if present). Note: +gtk3 variant is more of a stub (untested).

su_v (suv-lp) wrote :

MacPorts has now updated gtk-osx-application to 2.0.1, too:

su_v (suv-lp) wrote :

'' removed - MacPorts maintainer needs to find better solution to address build failure in 'src/coca-menu-item.c':
(Note: unpatched verison fails with clang on Lion, workaround: use llvm-gcc.4.2 instead)

su_v (suv-lp) on 2017-01-12
tags: added: gtk-quartz
removed: gtk-osx
Qantas94Heavy (qantas94heavy) wrote :

Further native macOS integration works is now being tracked here:

Changed in inkscape:
status: New → Invalid
tags: added: bug-migration
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.