~suv, thanks for the comments.
I've uploaded Inkscape-0.48.4-Lion-x86_64.dmg to
This is compiled from the 0.48.4 tarball with my modifications, launches with ScriptExec; it has no aspell dictionaries but -en.
On 1/3/13 1:28 PM, ~suv wrote:
On 03/01/2013 19:31, Valerio Aimale wrote:
If you could upload your changes to the packaging scripts as well as any additional scripts (not sure how you packaged the python modules), this would allow others (not using Mountain Lion yet) to test local packages... You could for example push a new branch on launchpad.net, similar to the one for this blueprint: https://blueprints.launchpad.net/inkscape/+spec/inkscape-quartz Branch: https://code.launchpad.net/~inkscape.dev/inkscape/dev-osx Or
- if you are not familiar with bzr and launchpad - you could file a
new bug report and attach a diff to the report. I'll add some quick initial comments below, based on the currently available information about your package:
I'm creating a branch, but I'll need somebody to authorize me to join the dev team in order to publish it under the ~inkscape/ team
- the Platypus-derived ScriptExec executable might not be needed anymore
Unless code is added to the binary inkscape itself (along with further desktop integration), using a shell script as launcher will not support any features of the dock and the native launch services - at least the shell-launcher script from gtk-mac-bundler (gtk-osx) has these issues:
Bug #1045959 https://bugs.launchpad.net/inkscape/+bug/1045959 [inkscape-quartz] add DnD, 'Open with…' support for Dock & Finder icon
- in this version, the app bundle executes the sh script directly.
Do extensions which themselves call inkscape on the commandline (e.g. restack, or dimensions), work with this kind of bundle structure and naming convention(s)?
I have a ScriptExec that works, however there are more problems. Launching with ScriptExec, forks, instead of execve'ing the inkscape-bin. This causes an extra, unsightly, icon to appear in the dock. I don't particularly like it. And the extra icon can't be removed, I tried every trick known to man. I think the way to go is what GIMP does: the apple launcher launches a sh script that execve's inkscape-bin. Launcher and UI integration should be done in the executable not the launcher script.
- The version I packaged runs gtk-2.0+quartz. It does not need
X11/Xquartz anymore to run. This is the direction GIMP has gone to as well.
Which version of GTK+ 2.24 is included in the bundle? If the latest 2.24.14, does it include the patches from https://trac.macports.org/ticket/37330? Without those patches, Inkscape and GIMP builds had been basically unusable for me (crash e.g. whenever a text is highlighted in a text input box).
For me a major showstopper for releasing quartz-based packages of Inkscape (at least based on the experience with my own builds on OS X Lion) is
- Bug #1046068 https://bugs.launchpad.net/inkscape/+bug/1046068 “Inkscape (GTK+/Quartz) calls output extensions or crashes when
quitting while clipboard not empty“ which tends to make Inkscape crash on quit, whenever the clipboard had been used in the current session.
Another annoying clipboard-related crash with the Quartz backend of GTK+ seems to be fixed if using GTK+ 2.24 with the latest patches from the git branch (I haven't updated the bug report yet, because MacPorts only recently included at least two of the required fixes into the gtk2 port):
- Bug #528632 https://bugs.launchpad.net/inkscape/+bug/528632 “GTK+/Quartz: crash in
Gtk::Editable_Class::set_selection_bounds_vfunc_callback (after clipboard_unset(…) )”
That patch is already applied to gtk-2.0 that comes with MacPorts 2.1.2, which is
gtk2 @2.24.14_1+no_x11+quartz (active)
However, inkscape still crashes when clicking in a text field. It might be an inkscape problem. If I can run a debug version, I'll look into it.
- It uses the same theme as GIMP. I think it's a good consistency
decision, and it's the theme that looks best on Mtn Lion.
Adwaita GTK2 (from gnome-themes-standard 3.6.x) isn't bad either and IMHO does integrate better with native OS X (at least on Lion), including the look of the scrollbars. But that's a minor detail at this point… ;)
For now, I'm compiling with murrine+Zukitwo+Mac themes. I think it's trivial to change it later.
 to quote Michael Wybrow on the same issue with Lion -> Snow Leopard:
I think it might be possible to build a package from Lion that runs on older machines, but it requires that everything (all the macports dependencies) be build against the Snow Leopard sdk instead of the default Lion one. I had some problems trying this in the past and just found it easier to use an older machine for the builds.