[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnustep-cvs] r33837 - in /libs/gui/trunk: ChangeLog Source/GSThemeM

From: Germán Arias
Subject: Re: [Gnustep-cvs] r33837 - in /libs/gui/trunk: ChangeLog Source/GSThemeMenu.m
Date: Tue, 13 Sep 2011 12:34:55 -0600

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]