gnustep-dev
[Top][All Lists]
Advanced

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

Re: [Gnustep-cvs] r31864 - in /libs/gui/trunk: ChangeLog Source/NSSavePa


From: Germán Arias
Subject: Re: [Gnustep-cvs] r31864 - in /libs/gui/trunk: ChangeLog Source/NSSavePanel.m
Date: Tue, 11 Jan 2011 19:31:07 -0600

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




reply via email to

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