Wasn't able to test it yesterday, will try to today. I don't suspect any issues.
GC On Mon, Sep 19, 2011 at 9:37 AM, Gregory Casamento <[email protected]> wrote: > 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 <[email protected]> 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<[email protected]> 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. >> >> > > -- > Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc. > yahoo/skype: greg_casamento, aol: gjcasa > (240)274-9630 (Cell) > -- Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc. yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell) _______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
