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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>>> 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) _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
