What works better for me with the 4th package:

°) Closing a second document window opened from within Inkscape.app no longer blanks the menubar - this is a major improvement compared to the prior package.

Other issues related to the menu-integration persist (at least in my tests on OS X 10.7.4):

°) Checkmarks/radio buttons in (sub-)menus are not reliably updated compared to X11- _and_ Quartz-based builds without menu integration:

- View modes (View > Display Mode): The menu items work, but the checkmark doesn't update to the chosen setting. Steps to reproduce e.g.: 1) launch Inkscape.app (with default preferences) 2) draw a simple shape 3) switch to menu 'View > Display Mode > Outline' 4) open 'View > Display Mode' again and check the status: it still claims 'Normal' to be active, despite the content of the current window is being shown in outline view mode. This can pose more of a usability problem e.g. with 'No Filter' view mode (may be less obvious at first sight compared to 'Normal') when using Inkscape in fullscreen mode <F11> (since the mode otherwise is also displayed in the titlebar of the current document window). A bug upstream in current GTK+/Quartz (window title bar is blank when restoring normal view after fullscreen <F11> [1]) doesn't help either (the information about the view mode is then missing too, besides the current file name).

- Toolbar layout settings (View > Normal | Custom | Wide) The checkmark is not updated if a different toolbar layout is chosen, and the toolbars of the current document window have been updated (rearranged). The three menu items (choices) also don't seem to always connect to the current active document window (if more than one window is open, the changed setting may affect the first opened instead of the current active one).

- Visibility status (View > Show/Hide): All items in that sub-menu initially have the status 'Hidden' (all are unmarked aka invisible), irrespective of the current state (which is saved across sessions). ° the first time used in the current session, they try to 'show' the chosen item irrespective of the current status: this has only an effect if the item is currently not visible (e.g. because it was hidden last time when Inkscape was quit). ° for already visible items (all, with default settings) an entry of the sub-menu 'Show/Hide' is only effective after having chosen it a second time (i.e. after selecting the menu item twice, the status is correctly reflected in the sub-menu). After that, each change later on is also correctly reflected in the sub-menu. The issue occurs each time the application is launched.

°) Recently used files 'File > Open Recent' is not working. This is more of a problem on OS X than on Ubuntu with Unity AFAICT, because with the current osx packaging method, files can be opened only from within Inkscape.app, instead of also from the file manager (Finder has various options to offer a list of recently used files), or via Dock icon (drag&drop, context menu). Luckily the list of recently used files in the 'File > Open' dialog does work (like under Unity) - the only option right now to quickly access various files currently being worked on.

°) No hints for menu items (not mentioned before) X11- and Quartz-based builds without menu-integration show hints for a highlighted menu item in the status bar. This does not work if the global OS X menubar is used (no messages in the status bar, no tooltips either).

°) Console warnings flood the system log An apparently long-standing issue with 'GtkosxApplication' from gtk-mac-integration (present in all three attempts during the past 14 months to update Inkscape's mac-menu-integration code which I tested in local builds): thousands of console warnings flooding the system log. According to [3], it seems related or connected to why the keyboard shortcuts are not displayed in the menus. (tbh, I would personally not use this package as regular app from the dock or the finder because of this. Each - even short - Inkscape session simply floods the system log, and makes e.g. Console.app (default settings of non-admin account) barely usable to track messages from other applications or events. Probably less (or not) an issue for regular users).

Not due to the menu-integration, but to packaging in general:

°) Extensions do not work: lxml still fails to import The bundled python lxml module (etree.so, etc) is linked against a newer version of libxml2 from the custom MacPorts tree, which is higher than what ships with the system on Lion and Mountain Lion (i.e. not compatible). According to [2], Lion 10.7.4 and 10.7.5 ship with the same version, and I don't really have a clue why it apparently works for Victor - possibly he has python as well as the same newer version of libxml2 installed in '/opt/local' (default MacPorts prefix), or possibly MacPython (from python.org) and lxml in '/Library/Frameworks': unlike the old 0.48.2 package, Valerio's packages do not prepend '/usr/bin' to $PATH to always enforce the usage of the system python. On my laptop OTOH, '/opt/local' does not exist, and I never installed a custom python version (or any python module) into /Library.

----- [1] https://bugzilla.gnome.org/show_bug.cgi?id=669808#c1 [2] http://opensource.apple.com/: - 10.7.4, 10.7.5: libxml2 2.7.3 (compatibility version 10.0.0) - 10.8.2: libxml2 2.7.8 (compatibility version 10.0.0) - MacPorts: libxml2 2.8.0 (compatibility version 11.0.0) [3] https://bugs.launchpad.net/inkscape/+bug/721448/comments/18

On 12/01/2013 02:14, Victor / tokiop wrote:

Hi Valerio,

the unified menubar works well : with two open documents, it's always focused and effective on the active one.

I'm not sure about what to check for "dynamic menu items" :

Selecting "display> snap/magnetism" (not sure of the translation) in the unified menubar toggles the correct icons on/off in the document window. There is no checkmark in the menu indicating if snap/magnetism is activated in the unified menubar, but it's the same in X11 version.

Checkmark doesn't update when choosing Display > [ Default / Custom / Large ]. In X11 version they seem to be updated through the menu-item icons, which are missing in the native version.

Please detail if you need more specific testing.

Thanks again for the effort. Such improvements are great news for libre-graphics production. Inkscape is a very efficient and needed tool !

Victor

Le 11/01/13 20:48, Valerio Aimale a écrit :

...

~suv,

thanks as always for your insightful comments. Sorry for the belated reply, I've been busy with work.

99 times out of 100, refactoring is best. However, there are exceptions.

Refactoring the menubar machinery in a way that works for all platforms is a major undertaking. It would be a significant investment of time. I think it would be nice to be able to provide a 0.48.4 release to the Mac users out there, who have been left behind for quite some time.

I've come up with a solution that is not a hack, but not even refactoring. As a matter of fact, Inkscape has already 80 % of the code needed to work with a unified menubar.

Would you, Victor, or any other willing test this version:

https://rapidshare.com/files/2954353212/Inkscape-0.48.4-10.7%2B-x86_64.dmg

It has a unified MacOSX menu for all windows/document/views. I don't know, however, what the unified menu does to dynamic menu items. Check marks are there and they seem to be ok for me. This version has also a working python installation. The application menu Quit item is not yet integrated with the app. It will be soon.

~suv, I've seen you comments in the bug reports and will reply, as time permits.

Valerio

...

Commenting here even though the topic is quickly getting way above my head: Personally, I wonder whether it's really about adding some hack, or more about efforts at refactoring some of Inkscape's code base? As I had tried to convey with information provided in earlier replies, some of the issues with the menubar integration also seem to similarly affect Inkscape e.g. on Ubuntu under Unity with the global menu (no icons and keyboard shortcuts for menu items, the 'File > Open Recent' sub-menu is broken in the same way, the toggle state can get out of sync, e.g when working with multiple windows, etc).

Possibly a somewhat related discussion, started during an earlier effort to advance the OS X menu integration of Inkscape: http://inkscape.13.n6.nabble.com/Verbs-SPAction-versus-GtkAction-tt2806978.html

Maybe this should or could be addressed indeed by a refactoring of Inkscape's code base, possibly with increased focus on what GTK3 might offer right now or plans to support? AFAIU at least for the Quartz backend GTK3 already includes menubar integration code which does not require to depend / link against the external gtk-mac-integration library anymore (there's a small demo app installed alongside gtk3-demo, which uses the native global menubar on OS X [1]).

Similarly, the problem with the modifiers in my understanding is likely to require quite a bit of refactoring - GIMP 2.8 is my reference in this regard: AFAICT the GIMP team rewrote large parts of the modifier code last year [2] (IIRC after some refactoring had occurred in upstream GTK2 2.24 first), and now the application out-of-the-box seems to handle modifier keys depending on the backend used for GTK2: on OS X 10.7, my local X11-based build of GIMP 2.8.2 has the (usual) 'Ctrl' modifier in shortcuts, whereas the Quartz-based build of the same GIMP version uses 'Cmd' instead. This is what I'd also like to expect from Inkscape.

On 15/01/2013 03:42, Valerio Aimale wrote:

...

Not due to the menu-integration, but to packaging in general:

°) Extensions do not work: lxml still fails to import The bundled python lxml module (etree.so, etc) is linked against a newer version of libxml2 from the custom MacPorts tree, which is higher than what ships with the system on Lion and Mountain Lion (i.e. not compatible). According to [2], Lion 10.7.4 and 10.7.5 ship with the same version, and I don't really have a clue why it apparently works for Victor - possibly he has python as well as the same newer version of libxml2 installed in '/opt/local' (default MacPorts prefix), or possibly MacPython (from python.org) and lxml in '/Library/Frameworks': unlike the old 0.48.2 package, Valerio's packages do not prepend '/usr/bin' to $PATH to always enforce the usage of the system python. On my laptop OTOH, '/opt/local' does not exist, and I never installed a custom python version (or any python module) into /Library.

Several issues here:

• Inkscape cannot use python modules from the System default python.

Here's the why. Inkscape depends on uniconvertor, which in turns depends on sk1libs. Sk1libs, in its turn, depends on freetype2 and little cms. Both are unavailable in a standard Mac OS X distribution. Python modules that are shipped with Inkscape should depend on macports libraries for those reasons. I've found an elegant solution, to rewrite dynamic linker dependencies such that python modules from macports can be bundled into Inkscape and still work. Next package will have full python support.

Note: UniConvertor is an _optional_ dependency, not a required one, and has never been included in the package for Mac OS X [1]. Since it is used as python module in the extensions, Inkscape cannot check for its presence, and still loads the input/output extensions even if they fail to work.

I don't really understand the relevancy of UniConvertor 1.1.5 here unless related to bug #1046068 https://bugs.launchpad.net/inkscape/+bug/1046068 which erroneously may trigger UniConvertor-based output extensions (or any other random output extension) on exit (expected behavior would be to simply quit silently, or to save and quit, without triggering additional output extensions).

If on the other hand you ported UniConvertor 1.1.5 to OS X, and manage to include a fixed and functional UniConvertor python module in Inkscape.app, this would certainly be a great bonus feature for Inkscape on OS X (though by itself this is no fix for bug #1046068).

----- [1] UniConvertor was not ported to Mac OS X by the sk1 team, and development & maintenance of UniConvertor 1.x has stopped upstream.

Even if one manages to install UniConvertor 1.1.5 on OS X, the package is only partially functional (IIRC from the time I tried (on 10.5.8), the internal font path for example is simply set to '/' which even on a modestly sized hard drive caused a time out / failure of any conversion if font names had been involved).