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

[Gregory Casamento]

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
<address@hidden> 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 <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.
>>
>>
>
> --
> 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)