gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Menu items issues with menu in window


From: Fred Kiefer
Subject: Re: Menu items issues with menu in window
Date: Thu, 10 Mar 2011 11:16:54 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.1.16) Gecko/20101125 SUSE/3.0.11 Thunderbird/3.0.11

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]