Re: [Gnustep-cvs] r33837 - in /libs/gui/trunk: ChangeLog Source/GSThemeMenu.m

[Fred Kiefer]

On 13.09.2011 20:34, Germán Arias wrote:
> On mar, 2011-09-13 at 19:45 +0200, Fred Kiefer wrote:
> > Am 13.09.2011 um 18:47 schrieb Richard Frith-Macdonald<address@hidden>:
> >
> > > On 13 Sep 2011, at 09:36, Fred Kiefer wrote:
> > >
> > > > On 13.09.2011 03:45, � wrote:
> > > > > Author: espectador
> > > > > Date: Tue Sep 13 03:45:13 2011
> > > > > New Revision: 33837
> > > > >
> > > > > URL: http://svn.gna.org/viewcvs/gnustep?rev=33837&view=rev
> > > > > Log:
> > > > > Improvements to menu in window
> > > > >
> > > > > Modified:
> > > > >     libs/gui/trunk/ChangeLog
> > > > >     libs/gui/trunk/Source/GSThemeMenu.m
> > > >
> > > > This patch looks like just another one in the long list of horrible changes to 
> > > > support in-window menus. Not that this patch helps in any way, it just keeps 
> > > > the impression that in-window menus are working up a bit more. If I understand 
> > > > it correctly, this patch is trying to replace the Windows sub menu whenever the 
> > > > menu gets set again on a window. What is the point of this? All the other menu 
> > > > and sub menu entries might just change as much as the Windows sub menu. Why add 
> > > > any special handling here? If you are really interested in in-window menus, 
> > > > which I am not, then you should start to look for real solutions, which would 
> > > > be the decoupling of NSMenu and NSMenuView, and not just add another layer of 
> > > > hacks to the code.
> > > >
> > > > Why can't the people interested in in-window menus form a special interest 
> > > > group. Discuss possible solutions and then come back with a proper proposal to 
> > > > implement this, instead of making random changes to the gui classes?
> > > >
> > > > Sorry, I know this isn't a polite way of putting this, but the in-window menu 
> > > > code has annoyed me a lot already and I really regret adding that possibility 
> > > > at all into gui.
> > > > As I stated before, I am even willing to help to develop a concept here. What I 
> > > > don't want to do is maintain all these hacks in gui.
> > >
> > > I'm not really interested in in-window menus either, but in the spirit of 
> > > making helpful suggestions about supporting them ...
> > >
> > > How about having entry-to/exit-from in window menu mode leave the existing menu 
> > > code largely unaltered, and just move the menu window off-screen so it can''t 
> > > be seen while in-window menus are in force?
> > >
> > > The the in-window menus could be implemented simply by creating toolbars in 
> > > each window  (these would live in the window decoration view, outside the 
> > > window's content view).
> > > The toolbars would be populated by examining the items in the main menu and 
> > > copying them.
> > > Submenus would be implemented as pop-up menus for the toolbar items.
> > > I think probably such a scheme could be almost entirely separate from the 
> > > normal menu code, and thus be implemented fairly cleanly rather than by hacking 
> > > existing menu views (though there would need to be some mechanism for passing 
> > > changes of state, eg NSMenuValidation, of the 'real' main menu to the toolbars 
> > > ... perhaps simply notifications).
> > > Just an thought.
> >
> >
> > What you are suggesting would result in about the same amount of in-window menu 
> > support as we have now. The basic display works quite well, what doesn't is the 
> > update of the menu.
> > I think what we should do is create a new NSMenuView and not set it as the 
> > representation of the menu, but link it up to the menu. That way we should get 
> > all the needed update notifications. And if we are missi g out on some, we need 
> > to improve NSMenu to use a different way to communicate with its 
> > representations. But as I am not that much interested in in-window menus, we 
> > need someody else willing to test this.
>
> Instead put a copy of main menu in each window, we can change the menu
> representation according to the main window. So, we can have only one
> menu instead a lot of copies.

There is a slight difference to my position. You are talking about the 
one menu representation that exists per menu. I would like to weaken 
that up and allow multiple representations to follow the same menu. The 
code in [GSTheme -setMenu:forWindow:] could then look something like this:

- (void) setMenu: (NSMenu *)menu
       forWindow: (NSWindow *)window
{
  GSWindowDecorationView *wv = [window windowView];

  // Remove any possible old menu view
  [wv removeMenuView];

  if (menu != nil)
  {
    NSMenuView *menuView = [[NSMenuView alloc] initWithFrame: NSZeroRect];

    [menuView setMenu: menu];
    [menuView setHorizontal: YES];
    [wv addMenuView: menuView];
    [menuView sizeToFit];
    RELEASE(menuView);
  }
}

I am not saying that this will work out of the box, it is highly likely 
that using menus that way will uncover plenty of problem we still have 
with menus. But this code wouldn't for a change be another hack, it 
would be a clean way forward and all bugs discovered and fixed in that 
process would be beneficial to GNUstep.
The problems will be most likely in the area where we expect that there 
is only one representation for each menu and that the menu already knows 
about that. We need to change code using that paradigm to be centred on 
the menu view instead.