Re: Menu items issues with menu in window

[Fred Kiefer]

Sorry, I am not interested in in-window menus. I was just trying to be helpful. 
But if there isn't anybody else willing to support that code, it will stay 
broken.
If copying an NSMenu doesn't give you a clean copy than this is a bug. Please 
report that with a short example to the bug tracker and I will have a look.

Fred

-------- Original-Nachricht --------
> Datum: Tue, 15 Mar 2011 10:06:37 -0400
> Von: Gregory Casamento <address@hidden>
> An: Fred Kiefer <address@hidden>
> CC: address@hidden
> Betreff: Re: Menu items issues with menu in window

> 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.