gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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: Sun, 18 Sep 2011 21:10:50 -0400

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.
>>
>>
>
>
>
>



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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]