Re: Menu items issues with menu in window

[Germán Arias]

Currently I'm testing Gemas.app with menu in window, and I add this hack
to avoid this problem. I'm not sure if this ensure a perfect work or if
this is needed on OS Windows. This is the hack (if is useful for someone
or if someone have a better hack), at method -awakeFromNib in
GemasDocument.m I add:

//Handle the Windows menu, to prevent crash with menu in window
  if (NSInterfaceStyleForKey(@"NSMenuInterfaceStyle", nil) ==
      NSWindows95InterfaceStyle)
    {
      id window;
      NSMenu *windowsMenu;
      NSEnumerator *windows = [[NSApp windows] objectEnumerator];
      
      while((window = [windows nextObject]))
        {
          if ((window != documentWindow) && [window menu] != nil)
            {
              NSMenuItem *new = AUTORELEASE([NSMenuItem new]);
              [new setTitle: [self displayName]];
              [new setTarget: documentWindow];
              [new setAction: @selector(makeKeyAndOrderFront:)];
              [new setImage: [NSImage imageNamed: @"common_Close"]];
              
              windowsMenu = [[[window menu] itemWithTitle: _(@"Windows")]
submenu];
              [windowsMenu insertItem: new atIndex: 1]; 
            }
        }
    }

And in delegate method -windowWillClose (in the same source file):

  //Handle the Windows menu, to prevent crash with menu in window
  if (NSInterfaceStyleForKey(@"NSMenuInterfaceStyle", nil) ==
      NSWindows95InterfaceStyle)
    {
      int x;
      id window;
      NSMenu *windowsMenu;
      NSEnumerator *windows = [[NSApp windows] objectEnumerator];
      
      while((window = [windows nextObject]))
        {
          if ((window != documentWindow) && ([window menu] != nil))
            {
              windowsMenu = [[[window menu] itemWithTitle: _(@"Windows")]
submenu];
              x = [windowsMenu indexOfItemWithTitle: [self displayName]];
              [windowsMenu removeItemAtIndex: x];
            }
        }
    }

And this solve the problem.


On mar, 2011-04-12 at 00:26 +0200, Wolfgang Lux wrote:
> I wrote:
> 
> > 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.
> >
> > 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 ...
> 
> In fact, I'd like to see this done in the short run. To see that the  
> current approach of making a copy is fundamentally broken, start up  
> Ink, open a second window, close the first window, and have a look at  
> the Windows menu of the second window: It still contains an entry for  
> the closed window. Now open a just a next window ... and see Ink go  
> with a segmentation violation.
> 
> Simply making a copy of the original menu isn't enough. We *must*  
> track changes in the original menu and apply them to every copy of the  
> menu -- at least until a better solution is implemented. Without that  
> change, NSWindows95InterfaceStyle is basically useless for any non- 
> trivial program.
> 
> Wolfgang
> 
> 
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnustep-dev