Re: Menu items issues with menu in window

[Gregory Casamento]

Fred,

I thought I tried using copy and had some issues since it creates a
shallow copy of the data structure.

What was needed was distinct instances of the same menu data without
pointing to the same menu structures so that yet keeping all copies up
to date with one another so that a new menu view instance could be
created for each NSMenu instance and added to each NSWindow which is
eligible to have one.

Please feel free to try using copy to implement this, but, at the time
I tried it, it didn't work for me the way I wanted.

GC

On Mon, Mar 14, 2011 at 11:59 AM, Fred Kiefer <address@hidden> wrote:
> I just had another look at the code in GSTheme -setMenu:forWindow:. Why do
> we archive the menu to copy it? The comment there says something about
> copying the view, but this surely isn't happening. NSMenu itself implements
> copy and this would result in the correct result. On the other hand I don't
> understand what is going on here and really don't want to. All this code
> looks hackish to me and I don't want to get involved with it to deeply.
>
> Fred
>
> On 10.03.2011 11:16, Fred Kiefer wrote:
>>
>> 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.
>
>
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnustep-dev
>



-- 
Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc.
yahoo/skype: greg_casamento, aol: gjcasa
(240)274-9630 (Cell)