On mar, 2011-09-13 at 19:45 +0200, Fred Kiefer wrote: > Am 13.09.2011 um 18:47 schrieb Richard Frith-Macdonald > <[email protected]>: > > > > > 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. _______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
