[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: 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.
- Re: [Gnustep-cvs] r33837 - in /libs/gui/trunk: ChangeLog Source/GSThemeMenu.m, Fred Kiefer, 2011/09/13
- Re: [Gnustep-cvs] r33837 - in /libs/gui/trunk: ChangeLog Source/GSThemeMenu.m, Germán Arias, 2011/09/13
- Re: [Gnustep-cvs] r33837 - in /libs/gui/trunk: ChangeLog Source/GSThemeMenu.m, Gregory Casamento, 2011/09/14
- Re: [Gnustep-cvs] r33837 - in /libs/gui/trunk: ChangeLog Source/GSThemeMenu.m, Fred Kiefer, 2011/09/18
- Re: [Gnustep-cvs] r33837 - in /libs/gui/trunk: ChangeLog Source/GSThemeMenu.m, Gregory Casamento, 2011/09/18
- Re: [Gnustep-cvs] r33837 - in /libs/gui/trunk: ChangeLog Source/GSThemeMenu.m, Germán Arias, 2011/09/18
- Re: [Gnustep-cvs] r33837 - in /libs/gui/trunk: ChangeLog Source/GSThemeMenu.m, Gregory Casamento, 2011/09/18
- Re: [Gnustep-cvs] r33837 - in /libs/gui/trunk: ChangeLog Source/GSThemeMenu.m, Fred Kiefer, 2011/09/19
- Re: [Gnustep-cvs] r33837 - in /libs/gui/trunk: ChangeLog Source/GSThemeMenu.m, Gregory Casamento, 2011/09/19
- Re: [Gnustep-cvs] r33837 - in /libs/gui/trunk: ChangeLog Source/GSThemeMenu.m, Gregory Casamento, 2011/09/20