That's not 0.48.4 that you packaged, that was from trunk. If you want to try packaging 0.48.4 for Mountain Lion you should grab an official release tarball such as http://sourceforge.net/projects/inkscape/files/inkscape/0.48.4/inkscape-0.48...

Thanks for taking an interest in this. Hopefully someone who is more familiar with our packaging on OSX could chime in and/or give feedback.

Cheers, Josh

On Thu, Jan 3, 2013 at 10:31 AM, Valerio Aimale <valerio@...2940...> wrote:

Hello,

I am not an official packager, but I was eager to have an updated version of Inkscape for Mac OS X and I noticed that nobody is packaging the new version.

I've packaged it for Mountain Lion and x86_64. It should be considered a beta packaging. I've packaged from version 0.48+devel r12005

You can download it at:

https://rapidshare.com/files/3885726044/Inkscape_MountainLion_x86_64.dmg

The Mac Os X packaging infrastructure in the source tree is a bit ancient. Things I've noticed:

• configure.ac uses syntax that is not conforming anymore with

autoconf/automake/authohear 1.13. Going forward that should be updated.

• the scripts osx-build.sh os-app.sh needs update for the newest Xcode

versions. they don't work out of the box.

• the dylib base relocation infrastructure needed to be rewritten
• the Platypus-derived ScriptExec executable might not be needed anymore
• in this version, the app bundle executes the sh script directly.

Features:

• 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.

• 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.

If somebody want to try and report problems, I'd appreciate it

Valerio

---

Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

On 03/01/2013 19:31, Valerio Aimale wrote:

I've packaged it for Mountain Lion and x86_64. It should be considered a beta packaging. I've packaged from version 0.48+devel r12005

Please note that 0.48+devel r12005 is not a stable or new "version" - it's the current unstable development branch (for 0.49). Your package should be clearly labeled as (unstable) development snapshot build.

The stable release branch (on which the latest bug-fix release 0.48.4 is based on), is here: https://code.launchpad.net/~inkscape.dev/inkscape/RELEASE_0_48_BRANCH and the tarballs are hosted at sf.net as well as at launchpad.net.

If somebody want to try and report problems, I'd appreciate it

Unfortunately, your app doesn't run on OS X Lion (to be expected if built with MacPorts using default config [1]), and I can't test it, nor really comment on it since no details about the actual packaging have been shared.

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:

The Mac Os X packaging infrastructure in the source tree is a bit ancient. Things I've noticed:

• configure.ac uses syntax that is not conforming anymore with

autoconf/automake/authohear 1.13. Going forward that should be updated.

- Bug #1094576 https://bugs.launchpad.net/inkscape/+bug/1094576 “Patch for autogen.sh and configure.ac to support automake 1.13”

• the scripts osx-build.sh os-app.sh needs update for the newest Xcode

versions. they don't work out of the box.

Long-standing known issue ever since Snow Leopard was released (old src requires SDK 10.4, among other things, uses deprecated features, not ported to Cocoa, etc.).

I once tried to update it with minimal changes to make it at least build on Lion (let alone work as expected), but the changes are likely to be completely wrong (I don't know how to code in C/C++/Objective-C) ;) http://bazaar.launchpad.net/~suv-lp/+junk/inkscape-osxapp-stacked/revision/11559

• the dylib base relocation infrastructure needed to be rewritten

Not sure what issue you hit (some problems which made it fail for me had been reported in bug #532765 “osx packaging: issues with fixlib() in osx-app.sh”).

• 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)?

Features:

• 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(…) )”

• 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… ;)

Regards, V

[1] 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.

~suv, thanks for the comments.

I've uploaded Inkscape-0.48.4-Lion-x86_64.dmg to

http://rapidshare.com/files/2708845162/Inkscape-0.48.4-Lion-x86_64.dmg

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.

...

Features:

• 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.

Valerio

Regards, V

[1] 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.

On 04/01/2013 22:05, Valerio Aimale wrote:

~suv, thanks for the comments.

I've uploaded Inkscape-0.48.4-Lion-x86_64.dmg to

<snip>

This is compiled from the 0.48.4 tarball with my modifications, launches with ScriptExec; it has no aspell dictionaries but -en.

Some comments about the bundled Python modules (Note: I can't test run the app myself):

1) Python modules with dynamically linked shared libraries

The launcher script 'Resources/bin/inkscape' sets these env variables:

# Put /usr/bin at beginning of path so we make sure we use Apple's python # over one that may be installed be Macports, Fink or some other means. export PATH="/usr/bin:$PATH"

# On Snow Leopard, use the 32-bit version of python from Universal build. # This is because our bundled i386 python libraries are 32-bit only. export VERSIONER_PYTHON_VERSION=2.7 export VERSIONER_PYTHON_PREFER_32_BIT=no

# Setup PYTHONPATH to use python modules shipped with Inkscape export PYTHONPATH="$TOP/python/site-packages" # NB: we are only preprending some stuff to the default python path so if the directory does not exist it should not harm the rest

# No longer required if path rewriting has been conducted. # export DYLD_LIBRARY_PATH="$TOP/lib"

combined with this:

$ otool -L Resources/python/site-packages/lxml/etree.so Resources/python/site-packages/lxml/etree.so: /opt/local/macports-with-a-very-looooooooooooooooooooooooooong-name/lib/libxslt.1.dylib (compatibility version 3.0.0, current version 3.27.0) /opt/local/macports-with-a-very-looooooooooooooooooooooooooong-name/lib/libexslt.0.dylib (compatibility version 9.0.0, current version 9.16.0) /opt/local/macports-with-a-very-looooooooooooooooooooooooooong-name/lib/libxml2.2.dylib (compatibility version 11.0.0, current version 11.0.0) /opt/local/macports-with-a-very-looooooooooooooooooooooooooong-name/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.7) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0) $

is (AFAIU) unlikely to work outside of your system, or as soon as that MacPorts tree no longer exists under the current path.

Inkscape spawns the first 'python' found in $PATH (which is /usr/bin/python), $DYLD_LIBRARY_PATH is not set (intentionally, consider it "evil" ;-) ), and the python process is unlikely to find the linked libraries (mainly libxslt, libexslt) installed into that specific prefix, and fail to properly import modules like lxml.

Ever since Inkscape.app got rid of depending on $DYLD_LIBRARY_PATH to find & load the bundled libs, included python modules with binary components need to be built statically linked against the system python version (unless alternatively a minimal functional (relocatable) python installation is included in the app bundle). At least this was the conclusion from bug #482993 [1].

Last fall, when I had tried to revive the X11-based packaging scripts on Lion, I wrote a small script to locally compile & install the lxml module for the system python version (2.7) with static dependencies into the 'packaging/macosx/Resources' folder (to have it automatically be added to the bundle when running osx-app.sh (called by osx-build.sh)). http://bazaar.launchpad.net/~suv-lp/+junk/inkscape-osxapp-stacked/view/head:/packaging/macosx/osx-lxml.sh IIRC extensions executed with the resulting Inkscape.app worked as expected (using the system python 2.7 in 64bit mode) even after having removed / renamed the current MacPorts tree, the build and install directories for inkscape and lxml.

Please note: the script hasn't been updated since, wasn't thoroughly tested (i.e. is likely to contain errors), and never was in any way integrated into the existing sets of scripts (one needed to run first, manually, before creating the rest of the app bundle). Maybe you can make use of it nevertheless (the variables (lxml version) and paths will need some tweaking - at the time I had also experimented with simplifying/reorganizing the bundle structure slightly).

I'm also attaching a small python extension [2] which was useful to me to test which version of python is spawned by Inkscape.app (this version no longer depends on inkex.py and thus now works even if lxml cannot be found. It reports the paths of the python binary and other information about the environment as seen by the spawned python process).

2) Minimally required modules to be included

The python-based extensions shipping with Inkscape require all 'lxml', and some additionally import numpy. 'lxml' needs to be bundled with Inkscape.app, 'numpy' OTOH has been included by Apple for its system python versions since Snow Leopard, and does not need to be included in the app bundle anymore (this has been confirmed for Snow Leopard and Lion, and is likely to also apply to Mountain Lion).

3) Just in case...

The packaging scripts may try to download an (outdated) DMG with precompiled python modules from modevia.com: this file is no longer hosted there. I have uploaded a copy to my DropBox account for now: http://dl.dropbox.com/u/65084033/devel/macosx/Python-packages.dmg though this would only be of interest when creating app bundles which run on older versions of OS X (currently not the case).

Regards, V

[1] https://bugs.launchpad.net/inkscape/+bug/482993 https://bugs.launchpad.net/inkscape/+bug/482993/comments/6 https://bugs.launchpad.net/inkscape/+bug/482993/comments/59 [2] latest version also available here (py-info.{inx,py}): http://bazaar.launchpad.net/~suv-lp/+junk/inkscape-extensions/files/head:/debug/

On 06/01/2013 16:42, Victor / tokiop wrote:

Hi Valerio,

great to have a working build system and X11-independant ! It launches well here (Lion / 10.7.5).

My bad - it seems that I got fooled by an error message from gdb without giving it a second thought:

$ gdb ./bin/inkscape GNU gdb 6.3.50-20050815 (Apple version gdb-1752) (Sat Jan 28 03:02:46 UTC 2012) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-apple-darwin"..."/private/tmp/Inkscape_MountainLion_0_48_4.app/Contents/Resources/bin/inkscape": not in executable format: File format not recognized

(gdb) q

I should of course have tested 'bin/inkscape-bin' (since the second package uses the old bundle structure), instead of blindly taking "File format not recognized" as the same issue I had with the first package.

Indeed, it does indeed launch and run on Lion 10.7.4, too… :)

Apologies again for my stupid mistake!

Didn't test it intensively, but quick feedback :

• no python "missing lxml" error while I have it on my current version

(the last mac official release I guess), great !

I get this error with regard to the lxml module (Lion 10.7.4, Xcode 4.3.2 - yes, I'm missing the latest round of updates):

The fantastic lxml wrapper for libxml2 is required by this extension.

Technical details: dlopen(/private/tmp/Inkscape_MountainLion_0_48_4.app/Contents/Resources/python/site-packages/lxml/etree.so, 2): Library not loaded: /opt/local/macports-with-a-very-looooooooooooooooooooooooooong-name/lib/libxml2.2.dylib Referenced from: /private/tmp/Inkscape_MountainLion_0_48_4.app/Contents/Resources/python/site-packages/lxml/etree.so Reason: Incompatible library version: etree.so requires version 11.0.0 or later, but libxml2.2.dylib provides version 10.0.0

which could be another reason to bundle lxml as statically linked module, as mentioned in my earlier reply...

• the "detachable tool-panes can't be re-attached (?)

The toolbars are blank when detached - AFAIU an upstream issue in GTK+/Quartz, already reported for Inkscape here:

- Bug #539759 https://bugs.launchpad.net/inkscape/+bug/539759 “Mac Aqua: Dragged-off toolbars are borderless, blank white windows."

You can simply open a new document window (or use 'View > Duplicate Window' for the current document), to have all toolbars reattached again (the detached state of the toolbars is not saved).

The dockable dialogs OTOH can be detached and reattached without issues.

On 04/01/2013 22:05, Valerio Aimale wrote:

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.

Can't reproduce these crashes with your app bundle either: clicking in a text field and highlighting portions of text is ok, as well as adding new layers and renaming them.

I still get the known issue with various extension dialogs popping up after quitting, if having copy&pasted vector objects in the current document).

Regards, V (feeling bad about having made such a stupid mistake)

On 07/01/2013 08:13, Valerio Aimale wrote:

This is a good example of Mac OSX integration. Not complete, but, I'd say a good start.

https://rapidshare.com/files/2004754462/Inkscape-r9943-10.7%2B-x86_64.dmg

Many thanks for sharing this third build/package!

AFAICT the basics for the menubar integration are fine (Inkscape's dynamic sub-menus, for example), and working with multiple files from within the same Inkscape process is better supported, too.

1) Issues noticed with 'Inkscape-r9943-10.7+-x86_64' (on OS X 10.7):

- Menubar (blocker): Closing a second window opened from within Inkscape may empty the global menubar. The content of the menubar is restored e.g. when opening a new window again (with the keyboard shortcut, or button on the commands bar), or when switching between other document windows if there are still multiple ones open.

Steps to reproduce: 1) launch Inkscape.app (with default preferences) 2) open new (second) window with 'Ctrl+N' 3) close second window with 'Ctrl+W' --> the menubar now has only one menu ('Inkscape'), which basically allows to quit the application, but nothing else.

- Menubar: Menu items with a 'checkmark' (toggle state) don't update if the setting is changed (e.g. 'View > Display mode > { … | Normal | No Filters | Outline }' or don't reflect the initial state (e.g. items in 'View > Show/Hide').

- Extension modules: Import of lxml fails on Lion: system libs (libxml2 and libxslt) shipping with Lion [1] provide older versions than those that the python module was linked against:

$ otool -L /tmp/Inkscape-r9943-10.7+-x86_64.app/Contents/Resources/python/site-packages/lxml/etree.so /tmp/Inkscape-r9943-10.7+-x86_64.app/Contents/Resources/python/site-packages/lxml/etree.so: @executable_path/../lib/libxslt.1.dylib (compatibility version 3.0.0, current version 3.27.0) @executable_path/../lib/libexslt.0.dylib (compatibility version 9.0.0, current version 9.16.0) @executable_path/../lib/libxml2.2.dylib (compatibility version 11.0.0, current version 11.0.0) @executable_path/../lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.7) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)

$ otool -L /usr/lib/libxml2.2.dylib /usr/lib/libxml2.2.dylib: /usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current version 10.3.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5) /usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current version 46.1.0) $ otool -L /usr/lib/libxslt.1.dylib /usr/lib/libxslt.1.dylib: /usr/lib/libxslt.1.dylib (compatibility version 3.0.0, current version 3.24.0) /usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current version 10.3.0) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0) /usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current version 46.1.0) $ otool -L /usr/lib/libexslt.0.dylib /usr/lib/libexslt.0.dylib: /usr/lib/libexslt.0.dylib (compatibility version 9.0.0, current version 9.13.0) /usr/lib/libxslt.1.dylib (compatibility version 3.0.0, current version 3.24.0) /usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current version 10.3.0) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0) /usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current version 46.1.0)

Rewriting the paths of *.so files in the bundled python modules doesn't help for compatibility with Lion (AFAIU for the spawned python process, "@executable_path" does not resolve relative to the path of the main Inkscape binary to make '/usr/bin/python' load libraries from inside the Inkscape application bundle, and the same libs loaded from '/usr/lib' are not compatible):

The fantastic lxml wrapper for libxml2 is required by this extension.

Technical details: dlopen(/tmp/Inkscape-r9943-10.7+-x86_64.app/Contents/Resources/python/site-packages/lxml/etree.so, 2): Library not loaded: @executable_path/../lib/libxml2.2.dylib Referenced from: /tmp/Inkscape-r9943-10.7+-x86_64.app/Contents/Resources/python/site-packages/lxml/etree.so Reason: Incompatible library version: etree.so requires version 11.0.0 or later, but libxml2.2.dylib provides version 10.0.0

- ...

At first sight the package otherwise seems to be at about the state of gellule's blueprint/branch (which was based on Inkscape trunk from Aug 2012), with similar (known) issues (see below).

I'll be more verbose tomorrow and replay to all emails. Too late now.

Thanks - looking forward to more detailed information… :)

Regards, V

----- 2) Known issues with 'gtk-mac-integration' (from gtk-osx) (originally tracked in bug #721448 and bug #738973):

- Menubar: thousands of console messages about "object class `GtkLabel' has no property named `accel-closure'" (bug #1043266)

- Menubar: menus display no keyboard shortcuts (bug #1043266 (gtk-osx), bug #998276 (Unity))

- Menubar: 'File > Open Recent' always opens file listed at the top (bug #1043266 (gtk-osx), bug #708185 (Unity), bug #752674 (Unity))

- Bundle: Missing Dock & Finder integration (bug #1045963)

- ...

3) Known issues with GTK+/Quartz:

- Quartz backend: Modifiers (Ctrl <-> Alt/Cmd) not swapped (bug #1043266, #438603)

- Quartz backend: screen updates may be slow or delayed (compared to X11-based builds) - noticeable e.g. with the pen tool, which is rather slow (delayed screen updates when rendering the red & green path handles?) if the window size is big (e.g. maximised) and the rulers are visible; or when rotating shapes interactively (the constantly updating status bar messages possibly cause additional delays, and the rotation arrows don't update until the LBM press is released).

- Blocker: Clipboard: Random calls to output extensions (or crash) on quit after having used the clipboard within the current session (bug #1046068)

- Clipboard: Import/export via system clipboard doesn't work as expected (bug #546934)

- ...

4) Other features related to OS X & packaging:

- Adjust menu structure if using 'gtk-mac-integration' on osx: move items like 'Preferences' and 'Input Devices' to the 'Inkscape' application menu (similar to GIMP 2.8.2 with GTK+/Quartz)

- Adjust location for preferences, shared and cached items (XDG spec) to the structure recommended by Apple (~/Library/*) if compiled with Quartz backend (or possibly only if linked with 'gtk-mac-integration')

- Fonts: there should be no more issues with current versions of pango and/or fontconfig which would prevent re-enabling the system fonts directory in 'Contents/Resources/etc/fonts/fonts.conf': <!-- <dir>/System/Library/Fonts</dir> --> (dfonts are handled ok; Helvetica on >= 10.7 seems fixed, bug #408190)

- ...

5) Issues with gellule's branch/bundling script solved (or improved) with your package(s):

- add gtk-themes support: new default theme, same as current GIMP 2.8.2 package for OS X (bug #1045963)

- include python modules for extensions (still needs support for Lion) (bug #1042597)

----- [1] According to information at Apple's opensource site: - OS X 10.7.5: libxml2-21.15.1, libxslt-10.10 http://opensource.apple.com/release/mac-os-x-1075/ - OS X 10.8.2: libxml2-22.3, libxslt-11.3 http://opensource.apple.com/release/mac-os-x-1082/

posted as a patch

https://bugs.launchpad.net/inkscape/+bug/1096996

Comments welcome.

Valerio

On 1/7/13 7:45 AM, ~suv wrote:

On 07/01/2013 08:13, Valerio Aimale wrote:

...

This is a good example of Mac OSX integration. Not complete, but, I'd say a good start.

https://rapidshare.com/files/2004754462/Inkscape-r9943-10.7%2B-x86_64.dmg

Many thanks for sharing this third build/package!

AFAICT the basics for the menubar integration are fine (Inkscape's dynamic sub-menus, for example), and working with multiple files from within the same Inkscape process is better supported, too.

1. Issues noticed with 'Inkscape-r9943-10.7+-x86_64' (on OS X 10.7):

• Menubar (blocker):

Closing a second window opened from within Inkscape may empty the global menubar. The content of the menubar is restored e.g. when opening a new window again (with the keyboard shortcut, or button on the commands bar), or when switching between other document windows if there are still multiple ones open.

Steps to reproduce:

1. launch Inkscape.app (with default preferences)
2. open new (second) window with 'Ctrl+N'
3. close second window with 'Ctrl+W'

--> the menubar now has only one menu ('Inkscape'), which basically allows to quit the application, but nothing else.

• Menubar:

Menu items with a 'checkmark' (toggle state) don't update if the setting is changed (e.g. 'View > Display mode > { … | Normal | No Filters | Outline }' or don't reflect the initial state (e.g. items in 'View > Show/Hide').

Your email, unfortunately, made me think that OSX menu integration might not be possible, without a major rewriting of the source code. Inkscape's architecture (as for the majority of gtk apps) assumes that, in multi-document mode, every window has its own private menu that receives and process events.

In OSX, in multi-dicument mode, there is only one menu that processes events and dispatches actions to the window that currently has the focus.

It might not be possible to achieve this type of integration with the current state of Inkscape' sources.

• Extension modules:

Import of lxml fails on Lion: system libs (libxml2 and libxslt) shipping with Lion [1] provide older versions than those that the python module was linked against:

...

$ otool -L /tmp/Inkscape-r9943-10.7+-x86_64.app/Contents/Resources/python/site-packages/lxml/etree.so /tmp/Inkscape-r9943-10.7+-x86_64.app/Contents/Resources/python/site-packages/lxml/etree.so: @executable_path/../lib/libxslt.1.dylib (compatibility version 3.0.0, current version 3.27.0) @executable_path/../lib/libexslt.0.dylib (compatibility version 9.0.0, current version 9.16.0) @executable_path/../lib/libxml2.2.dylib (compatibility version 11.0.0, current version 11.0.0) @executable_path/../lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.7) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0) $ otool -L /usr/lib/libxml2.2.dylib /usr/lib/libxml2.2.dylib: /usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current version 10.3.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5) /usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current version 46.1.0) $ otool -L /usr/lib/libxslt.1.dylib /usr/lib/libxslt.1.dylib: /usr/lib/libxslt.1.dylib (compatibility version 3.0.0, current version 3.24.0) /usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current version 10.3.0) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0) /usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current version 46.1.0) $ otool -L /usr/lib/libexslt.0.dylib /usr/lib/libexslt.0.dylib: /usr/lib/libexslt.0.dylib (compatibility version 9.0.0, current version 9.13.0) /usr/lib/libxslt.1.dylib (compatibility version 3.0.0, current version 3.24.0) /usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current version 10.3.0) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0) /usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current version 46.1.0)

Rewriting the paths of *.so files in the bundled python modules doesn't help for compatibility with Lion (AFAIU for the spawned python process, "@executable_path" does not resolve relative to the path of the main Inkscape binary to make '/usr/bin/python' load libraries from inside the Inkscape application bundle, and the same libs loaded from '/usr/lib' are not compatible):

Packing of python from the macports root installation directory was a wrong choice. Python numpy and lxml packages have to be packaged from the system-wide python 'site-packages'

I'll correct that.

Valerio

...

The fantastic lxml wrapper for libxml2 is required by this extension.

Technical details: dlopen(/tmp/Inkscape-r9943-10.7+-x86_64.app/Contents/Resources/python/site-packages/lxml/etree.so, 2): Library not loaded: @executable_path/../lib/libxml2.2.dylib Referenced from: /tmp/Inkscape-r9943-10.7+-x86_64.app/Contents/Resources/python/site-packages/lxml/etree.so Reason: Incompatible library version: etree.so requires version 11.0.0 or later, but libxml2.2.dylib provides version 10.0.0

• ...

At first sight the package otherwise seems to be at about the state of gellule's blueprint/branch (which was based on Inkscape trunk from Aug 2012), with similar (known) issues (see below).

...

I'll be more verbose tomorrow and replay to all emails. Too late now.

Thanks - looking forward to more detailed information… :)

Regards, V

---

2. Known issues with 'gtk-mac-integration' (from gtk-osx)

(originally tracked in bug #721448 and bug #738973):

• Menubar: thousands of console messages about "object class `GtkLabel' has no property named `accel-closure'" (bug #1043266)

• Menubar: menus display no keyboard shortcuts (bug #1043266 (gtk-osx), bug #998276 (Unity))

• Menubar: 'File > Open Recent' always opens file listed at the top (bug #1043266 (gtk-osx), bug #708185 (Unity), bug #752674 (Unity))

• Bundle: Missing Dock & Finder integration (bug #1045963)

• ...

3. Known issues with GTK+/Quartz:

• Quartz backend: Modifiers (Ctrl <-> Alt/Cmd) not swapped (bug #1043266, #438603)

• Quartz backend: screen updates may be slow or delayed (compared to X11-based builds) - noticeable e.g. with the pen tool, which is rather slow (delayed screen updates when rendering the red & green path handles?) if the window size is big (e.g. maximised) and the rulers are visible; or when rotating shapes interactively (the constantly updating status bar messages possibly cause additional delays, and the rotation arrows don't update until the LBM press is released).

• Blocker: Clipboard: Random calls to output extensions (or crash) on quit after having used the clipboard within the current session (bug #1046068)

• Clipboard: Import/export via system clipboard doesn't work as expected (bug #546934)

• ...

4. Other features related to OS X & packaging:

• Adjust menu structure if using 'gtk-mac-integration' on osx: move items like 'Preferences' and 'Input Devices' to the 'Inkscape' application menu (similar to GIMP 2.8.2 with GTK+/Quartz)

• Adjust location for preferences, shared and cached items (XDG spec) to the structure recommended by Apple (~/Library/*) if compiled with Quartz backend (or possibly only if linked with 'gtk-mac-integration')

• Fonts: there should be no more issues with current versions of pango and/or fontconfig which would prevent re-enabling the system fonts directory in 'Contents/Resources/etc/fonts/fonts.conf':

  <!-- <dir>/System/Library/Fonts</dir> -->

  (dfonts are handled ok; Helvetica on >= 10.7 seems fixed, bug #408190)

• ...

5. Issues with gellule's branch/bundling script solved (or improved)

with your package(s):

• add gtk-themes support: new default theme, same as current GIMP 2.8.2 package for OS X (bug #1045963)

• include python modules for extensions (still needs support for Lion) (bug #1042597)

---

[1] According to information at Apple's opensource site:

• OS X 10.7.5: libxml2-21.15.1, libxslt-10.10

http://opensource.apple.com/release/mac-os-x-1075/

• OS X 10.8.2: libxml2-22.3, libxslt-11.3

http://opensource.apple.com/release/mac-os-x-1082/

Just a comment.

When I build Gimp on the Mac (my builds are known as McGimp, I never leave any trace on the user's machine when uninstalled. No macport, no su etc.

I am planning on building Inkscape for the Mac as well, as soon as I sort out the font issues on the Mac. Inkscape uses deprecated functions that my pango does not recognize.

On Mon, Jan 7, 2013 at 2:28 PM, Valerio Aimale <valerio@...2940...> wrote:

posted as a patch

https://bugs.launchpad.net/inkscape/+bug/1096996

Comments welcome.

Valerio

---

Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

this is how to try my osx integration code

https://bugs.launchpad.net/inkscape/+bug/1097009

Valerio

Any updates on this?

The keyboard bug is hilarious but a killer and i'm not certain of the best way to resolve it having inspected the package.

there's a whole planet of folks waiting with baited breath for this. what can we do to help?

Andy

On Mon, Jan 21, 2013 at 5:30 AM, Valerio Aimale <valerio@...2940...> wrote:

It would be better to download one of these two:

This is really great to see native Mac builds worked on. I would love to test more RCs and offer feedback.

Any progress on related bugs being accepted and merged?

-- View this message in context: http://inkscape.13.x6.nabble.com/Mac-OS-X-Mountain-Lion-x86-64-packaging-of-... Sent from the Inkscape - Dev mailing list archive at Nabble.com.

So happy to see this thread taking off. Please let me know if anyone needs testing.

Andy

On Mon, Aug 26, 2013 at 10:43 PM, sugimoto605 <sugimoto605@...1026...>wrote:

I created similar one since above links are unavailable. The package is here < https://box.yahoo.co.jp/guest/viewer?sid=box-l-fsh6hu54cgcdbskmiuhgg5bygi-10...

...

but I have several difficulties:

1. Requires ImageMagick http://cactuslab.com/imagemagick/ and

GNU_Aspell < https://box.yahoo.co.jp/guest/viewer?sid=box-l-fsh6hu54cgcdbskmiuhgg5bygi-10...

...

2. sudo ln -s /Library/Fonts\ Disabled /usr/share/fonts to use

TimesNewRoman 3. Drag and drop does not work. You have to use other app < https://box.yahoo.co.jp/guest/viewer?sid=box-l-fsh6hu54cgcdbskmiuhgg5bygi-10...

...

to open file.

-- View this message in context: http://inkscape.13.x6.nabble.com/Mac-OS-X-Mountain-Lion-x86-64-packaging-of-... Sent from the Inkscape - Dev mailing list archive at Nabble.com.

---

Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clk... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

Hey, just wanted to point out that there are nearly nine thousand views on this thread, which is several orders of magnitude greater than almost any other thread here. Obviously there are a lot of people that are really interested in an up-to-date Mac version of Inkscape.

It's been almost a year since Valerio's last update on this. Is there anything we can do to help this along? Can anyone step in and pick up where this left off? Please??

-- View this message in context: http://inkscape.13.x6.nabble.com/Mac-OS-X-Mountain-Lion-x86-64-packaging-of-... Sent from the Inkscape - Dev mailing list archive at Nabble.com.