Re: Menu items issues with menu in window

[Gregory Casamento]

Sorry... I was up late last night working, I should know better than
to edit emails when I'm tired.   The second paragraph should read:

> What was needed was distinct instances of the same menu data without
> pointing to the same menu structures 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.

On Tue, Mar 15, 2011 at 10:05 AM, Gregory Casamento
<address@hidden> wrote:
> 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)
>



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