Re: [Gnustep-cvs] r33837 - in /libs/gui/trunk: ChangeLog Source/GSThemeM
From:
Gregory Casamento
Subject:
Re: [Gnustep-cvs] r33837 - in /libs/gui/trunk: ChangeLog Source/GSThemeMenu.m
Date:
Mon, 19 Sep 2011 09:37:16 -0400
>From looking at the code it doesn't seem like it should effect the WinUXTheme. I'll test and get back to you
On Monday, September 19, 2011, Fred Kiefer <address@hidden> wrote:
> I put the changes in the branch in_window_menu. Just do a switch to this and you will get the changes: > > svn switch svn+ssh://svn.gna.org/svn/gnustep/libs/gui/branches/in_window_menu
> > Up to now feedback on GNUstep changes in branches has been very slow. If I don't get any replies on this until early next week I commit these changes to trunk. I will be away for the weekend (Thursday to Monday, actually) if you are really interested in this change, better test it today :-)
> > On 19.09.2011 03:10, Gregory Casamento wrote: >> >> Hey Fred, >> >> I thought it had been committed... go ahead and put it in a branch >> and post the name of the branch back here.
>> >> Use your own discretion as to when to merge it back once everyone has >> taken a look at it. >> >> Later, GC >> >> On Sun, Sep 18, 2011 at 7:09 PM, Germán Arias<address@hidden> wrote:
>>> >>> On dom, 2011-09-18 at 16:39 +0200, Fred Kiefer 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. >>> >>> I think is better in a branch, while we test this and try to solve the
>>> remaining problems. >>> >>>> These are mainly in the tracking code, that has >>>> become so complicated that I wont dare to touch it. >>> >>> I wrote some of that code. So I can check this.
>>> >>>> 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.
> >