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 <[email protected]> > An: Fred Kiefer <[email protected]> > CC: [email protected] > 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 > <[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
