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
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> ) 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
°) 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 , 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
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 , 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.
- 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)
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 !
> Le 11/01/13 20:48, Valerio Aimale a écrit :
>> 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:
>> 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
>>> 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:
>>> 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 ).
>>> 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  (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.