Thanks for the comments, mine are below
A new package, which I consider an RC1 is coming.
°) 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.:
- launch Inkscape.app (with default preferences)
- draw a simple shape
- switch to menu 'View > Display Mode > Outline'
- 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).
I was on the wrong path. Inkscape cannot be forced into having a grand unified menubar for all windows. The architectural idea that each document window has its own menubar is pervasive in all inkscape source code. To change it, would mean to rewrite inkscape almost from scratch. After butting my head against the wall for a long while, I changed my approach and refactored my osx-integration code. Now, even in OSX, each window has its own menu; it gets switched when focus changes. It work beautifully
- 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).
All this has been fixed by the refactoring of my osx integration. See above.
- 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.
I think this has been fixed s well by the above.
°) 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.
I'll have to look into these. I focused on menubar and python issues.
°) 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).
No idea why so far.
°) 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).
I agree that gtk-based applications are annoying on the terminal. They flood stderr, for no apparent reason. A weird choice by gtk authors, early in the days. The problem is easily solved by launching inkscape with &>/dev/null. I added that bit. Re the integration library. Not using gtk-mac-integration would mean to rewrite a library that is largely similar, or write inkscape's own integration code. That would take quite some time. gtk-mac-integration works well and makes Inkscape look quite spiffy on mac. Regardless, it's not a bug in gtk-mac-integration. Modern gtk applications should use GtkAccelerators with their menuitems. Inkscape, being a little dated, does not use GtkAccelerators, but does its own menu acceleration, reading directly keyboard events via GDK. Gtk complains on the stderr that menu items don't have GtkAccelerators. I think it would be wise to switch Inkscape to standard menu accelerators.
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.
Valerio