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.