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 <[email protected]> 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 <[email protected]> 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 >> [email protected] >> 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) _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
