Am 08.03.2011 09:50, schrieb Wolfgang Lux:
Germán Arias wrote:
Some menu items becomes disabled with menu in window. For example with
Ink, the items "Bold", "Italic", "Larger" and "Smaller" are disabled
with menu in window. However, the short cut keys works fine. Some idea
about what is the problem?
Yes. It's due to a fundamental flaw in the way menus in windows are
handled at present. The problematic items in the font menu all have an
explicit target, namely the shared font manager. When attaching an
in-window menu to a window, GSTheme -setMenu:forWindow: makes a copy of
its menu argument using a temporary (non-keyed) archive. During this
process all explicit menu item targets are lost. Since no target in the
responder chain responds to the action of the bold, etc. items they
automatically get disabled.
I don't think that all explicit targets get lost here, just the ones
that don't know how to encode/decode themselves and the NSFontManager is
one of them. For that reason a keyed archiver wont help here.
We could try to work around this by encoding an NSFontManager as an
NSCustomObject as it gets done by InterfaceBuilder. But this seems like
another hack on top of the previous ones.
Maybe using a keyed archive instead of a non-keyed archive could help
here. But then you may as well end up with one or more copies of the
font manager. And even if you get this to work, you still have the
problem that the shared font manager maintains a reference to what it
thinks is the global font menu so that it can toggle the menu item
titles between Bold and Unbold, and Italic and Unitalic, respectively.
So, in the long run I'd prefer NSMenu were changed to handle multiple
menu views rather than having this menu duplication cruft. But it is
certainly too late for the next release ...
This surely is the way to go. NSMenu should loose its two windows and
the direct reference to the NSMenuView. All these connections should be
the other way around. Hopefully we make some progress in that direction
after the next release.