[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnustep-cvs] r33837 - in /libs/gui/trunk: ChangeLog Source/GSThemeM
Re: [Gnustep-cvs] r33837 - in /libs/gui/trunk: ChangeLog Source/GSThemeMenu.m
Tue, 13 Sep 2011 10:36:19 +0200
Mozilla/5.0 (X11; U; Linux x86_64; de; rv:220.127.116.11) Gecko/20110907 SUSE/3.1.14 Thunderbird/3.1.14
On 13.09.2011 03:45, � wrote:
Date: Tue Sep 13 03:45:13 2011
New Revision: 33837
Improvements to menu in window
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.