Josh, thank I might have packaged a more advanced version? In any case it was a test/beta packaging. The tarball you pointed at, has the sane issues with mac packaging I encountered. I will package that one. V. On 1/3/13 12:46 PM, Josh Andler wrote:

~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: 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 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. 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. For now, I'm compiling with murrine+Zukitwo+Mac themes. I think it's trivial to change it later. Valerio

On 04/01/2013 22:05, Valerio Aimale wrote: <snip> 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: combined with this: 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/he... 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:...

On 06/01/2013 16:42, Victor / tokiop wrote: My bad - it seems that I got fooled by an error message from gdb without giving it a second thought: 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! 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): which could be another reason to bundle lxml as statically linked module, as mentioned in my earlier reply... 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: 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: 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: 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): - ... 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). 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/>

Accelerator integration with OSX is a touch one to tackle. Inkscape uses GDK events to detect keystokes, instead of more modern GtkAccelerators. The Left Meta Key (or "Apple", "Command", "Windows flag" or "Windows start") is not properly detected in src/event-context.cpp. Once meta detection is achieved in src/event-context.cpp, it would be trivial to add support for Mac accelerators, modifying shortcuts.cpp shortcuts.h and keys/default.xml (replacing "Ctrl" with "Meta", where appropriate). Best, Valerio On 1/7/13 7:58 AM, ~suv wrote:

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:

I created similar one since above links are unavailable. The package is here <https://box.yahoo.co.jp/guest/viewer?sid=box-l-fsh6hu54cgcdbskmiuhgg5bygi... 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... 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... to open file. -- View this message in context: http://inkscape.13.x6.nabble.com/Mac-OS-X-Mountain-Lion-x86-64-packaging-... Sent from the Inkscape - Dev mailing list archive at Nabble.com.

this is how to try my osx integration code https://bugs.launchpad.net/inkscape/+bug/1097009 Valerio

~suv, the new launcher sh script is more gdb friendly, if oyu look at the top of the script. On 1/6/13 10:10 AM, ~suv wrote:

I see that the first Mac OSX package attempt (below) is still being downloaded: It would be better to download one of these two: Mountain Lon: http://rapidshare.com/files/1736402100/Inkscape-r0.48.4-r9943-10.8%2B-x86... Lion: http://rapidshare.com/files/3930886749/Inkscape-r0.48.4-r9943-10.7%2B-x86... Valerio On 1/3/13 11:31 AM, Valerio Aimale wrote:

On 2/3/13 5:24 PM, Andy Fitzsimon wrote: Andy, I've been busy with work related stuff. I'll put up another RC tonight. Valerio

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