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

[Fred Kiefer]

Hi German,

your latest patch looks very promising to me. What I didn't understand
is the line
+      else
+       {
+         [[self keyWindow] makeMainWindow];
+       }

When there is already a main Window, shouldn't we just keep that?
I will have a closer look at the whole patch over the weekend.

Thank you for your contribution
Fred


Am 13.01.2011 18:44, schrieb Germán Arias:
> The attached patch, revert the last changes in NSSavePanel and NSWindow,
> and put the appropriate code in NSMenuVIew. Also, there are a change in
> NSApplication. Here I save the main window, and restore it when unhide
> the app. If there isn't main window, set the key window as main window.
> I think this is more consistently, since the menu is not necessarily at
> key window. Or an app can have more than one window that can become the
> key window (for example GScheme). Try this patch for take ideas, add
> some changes or apply this. Regards.
> 
> 
> On jue, 2011-01-13 at 09:54 -0500, Gregory Casamento wrote:
>> 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