[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: Fred Kiefer
Subject: Re: [Gnustep-cvs] r33837 - in /libs/gui/trunk: ChangeLog Source/GSThemeMenu.m
Date: Sun, 18 Sep 2011 16:39:22 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv: Gecko/20110907 SUSE/3.1.14 Thunderbird/3.1.14

I played around with that code and have it basically working now. This version has about the functionality that our current in-window menu support in gui provides, but it is very likely to break the existing themes that offer extended support for this.

I could now either put that code into a branch where nobody would be using it. Or commit it to gui trunk and have other fix the remaining issues with that code. These are mainly in the tracking code, that has become so complicated that I wont dare to touch it. There we sometimes use the menu representation of the main menu, and this of course wont be correct any more. The actual used menu view wont be accessible from the main menu any more, as each window will use its own one.

If this is fixed and all the themes work again, then the next step may be done. in my opinion this would be the introduction of a new class GSMenuRepresentation that stands between the NSMenu and the NSMenuView. The main purpose of that class would be to hold the window we currently store in the NSMenu. Instead of the two windows NSMenu would have two GSMenuRepresentations one for the standard and one for the transient display. That class would delegate most of the operations on to the menu view. The important point here is not to use this class where it isn't needed. We should try to avoid any internal knowledge of the menu representation in gui (and even more in user code). That way we make it a lot easier for themes to replace the actual menu display implementation.

On 14.09.2011 21:48, Gregory Casamento wrote:
This change is certainly wrong.  Fred's assessment is correct.
Treating the Windows menu in a special manner is not going to fix the
overall issue.

I recall a discussion some weeks or months ago about this very subject
in which we all agreed that decoupling NSMenu and NSMenuView is the
correct solution.

I have been working on the buildtool and other things so that we can
build Xcode projects and can get rid of/deprecate pbxbuild so my
attention has been taken from this, but this should get back on my
radar within the next few weeks.

In-window menus on Windows are working quite well.  I believe the
reason that this approach works is that it does what fred is
describing.  When I wrote the code for the Windows theme that does
this it uses NSMenu as a model and builds the necessary Windows Menu
structures from it.  I expect when following the same paradigm for
adding them to the Gtk/GNOME theme (i.e. building the GtkMenu by
recursing the NSMenu structure) it will work equally well there too.
Both the windows and the gnome theme use the callback [GSTheme
setMenu:forWindow:] in the theming framework.

The callback in GSTheme is, I believe, correctly placed.   It's the
current in-window menus implemented in GNUstep which are the problem.
The implementation for this has never been perfect.  At first the
menus were being added only to the currently active window and removed
when the window lost key and added to the new key window.   This was
unacceptable.   When I added code to make the menu appear in all key
windows, this was something of a kludge to begin with.   So the state
of the current code for in-window menus is partly my fault.

That being said, I believe that no further changes should be made to
the code for GNUstep rendered in-window menus until we have time to
start working on the correct solution as suggested by Fred.

Later, GC

On Tue, Sep 13, 2011 at 4:36 AM, Fred Kiefer<address@hidden>  wrote:
On 13.09.2011 03:45, � wrote:

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

reply via email to

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