>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)
_______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
