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

[Gregory Casamento]

I'll take a look later today to see how this impacts the Windows and
GNOME themes.

GC

On Sun, Sep 18, 2011 at 10:39 AM, Fred Kiefer <address@hidden> wrote:
> 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
>>>>
>>>> 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.
>
>



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