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

[Gregory Casamento]

Fred,

I will revert it ASAP.   I would like to, however, find a better place
to do this.   For the next release I believe it's okay for us to close
the menus as we are doing now, but for the future releases we're going
to want to refactor things as I discussed.

I will try to find a better place to put this before reverting it.   I
will likely do that sometime tomorrow or this weekend.

Thanks, GC

On Thu, Jan 13, 2011 at 4:33 AM, Fred Kiefer <address@hidden> wrote:
> I agree with you on postponing the rewrite. We first need to understand
> what the correct behaviour would be. One thing though, could you revert
> the NSSavePanel change you made? This is definitely wrong and it is so
> easily forgotten, even after we clean up the menu handling.
>
> Fred
>
> Am 13.01.2011 06:35, schrieb Gregory Casamento:
>> I will start working on this this coming weekend, if needed.   I'm
>> wondering though, if we shouldn't hold off on starting this
>> refactoring effort until the after the next release.
>>
>> GC
>>
>> On Tue, Jan 11, 2011 at 8:31 PM, Germán Arias <address@hidden> wrote:
>>> On mar, 2011-01-11 at 16:42 -0500, Gregory Casamento wrote:
>>>> One other thing I would like to say on this is this:
>>>>
>>>> Currently the code which implements different kinds of menus is full
>>>> of if/then/else clauses in methods.
>>>> if it's win95 do this, otherwise do that.  That's a clear indication
>>>> to me that a refactorization is sorely needed.
>>>>
>>>> We need different menu classes for different menu types i.e.
>>>> NSMenuView should be an abstract class.    GSGNUstepMenuView (or
>>>> whatever) should draw the floating menus...  GSWin95MenuView should
>>>> draw the in-window menus...  GSMacMenuView should handle the Mac like
>>>> menus.
>>>> Something like that.
>>>
>>> I agree with this, because this way we can play with the code without
>>> worry about breaking something in the current code. And it is better
>>> since the recent changes are just patches to improve this (Since I have
>>> no enough knowledge to make a drastic change.) But if someone takes the
>>> first steps in this direction, I can help with that which is not low
>>> level.
>>>
>>>>
>>>> The trouble with how it's been done lays in it's reliance on the old
>>>> paradigm of handling events for the floating menu.  It's difficult
>>>> having so many paths through the same code to handle things
>>>> differently in this case or that.  I propose that we not only rethink
>>>> how we're handling events for in-window menus, but also how menus are
>>>> implemented at a very fundamental level.
>>>>
>>>> GC
>>>>
>>>> On Tue, Jan 11, 2011 at 2:51 AM, Wolfgang Lux <address@hidden> wrote:
>>>>> Gregory Casamento wrote:
>>>>>
>>>>>> Fred,
>>>>>>
>>>>>> I understand what you're saying, but I'm not sure what to do to
>>>>>> correct it.  I admit I had a feeling when I made this commit that
>>>>>> there must be a better way of doing this.  Something, perhaps, more
>>>>>> centralized is needed.    NSMenuView, as you suggested, does seem like
>>>>>> the right place.
>>>>>>
>>>>>> After some research it looks like _executeItemAtIndex:removeSubmenu:
>>>>>> might be a good candidate for this to be located centrally.
>>>>>>
>>>>>> Let me know what you think.
>>>>>
>>>>> I think the main problem is that NSMenuView's event tracking loop is too
>>>>> autistic. On one hand it accepts only mouse events during event tracking,
>>>>> but on the other hand it does not communicate this information to the 
>>>>> window
>>>>> manager and so the user can freely move or close windows while the loop is
>>>>> active. This is absolutely inconsistent. Either we must also grab the 
>>>>> mouse
>>>>> at the level of the X server during the event tracking, or the event
>>>>> tracking loop must handle AppKit generated events like window close and
>>>>> window move events. Personally, I'd prefer the latter, since grabbing 
>>>>> would
>>>>> make it impossible to enter a debugging session in the event loop (at 
>>>>> least
>>>>> without a second machine), but the former may be easier to implement.
>>>>>
>>>>> Wolfgang
>
>



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