Re: [Gnustep-cvs] r33837 - in /libs/gui/trunk: ChangeLog Source/GSThemeMenu.m

[Gregory Casamento]

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
>>
>> 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.
>
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>



-- 
Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc.
yahoo/skype: greg_casamento, aol: gjcasa
(240)274-9630 (Cell)