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 <[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
> >
> >
>
>
>
Index: Source/NSWindow.m
===================================================================
--- Source/NSWindow.m (revision 31886)
+++ Source/NSWindow.m (working copy)
@@ -1818,14 +1818,6 @@
if (_f.is_main == YES)
{
_f.is_main = NO;
-
- //We close the menu if the app will be hide
- if (NSInterfaceStyleForKey(@"NSMenuInterfaceStyle", self) ==
- NSWindows95InterfaceStyle)
- {
- [[[self menu] attachedMenu] close];
- }
-
if (_f.is_key == YES)
{
[_wv setInputState: GSTitleBarKey];
Index: Source/NSApplication.m
===================================================================
--- Source/NSApplication.m (revision 31886)
+++ Source/NSApplication.m (working copy)
@@ -1293,18 +1293,21 @@
[_hidden_key makeKeyWindow];
_hidden_key = nil;
}
+
+ if ([self mainWindow] == nil && _hidden_main != nil
+ && [[self windows] indexOfObjectIdenticalTo: _hidden_main] != NSNotFound)
+ {
+ [_hidden_main makeMainWindow];
+ _hidden_main = nil;
+ }
+ else
+ {
+ [[self keyWindow] makeMainWindow];
+ }
if ([self keyWindow] != nil)
{
[[self keyWindow] orderFront: self];
-
- /* If menu is in window, we need a main window, in other way
- the menu can't respond */
- if (NSInterfaceStyleForKey(@"NSMenuInterfaceStyle", self) ==
- NSWindows95InterfaceStyle && [[self keyWindow] canBecomeMainWindow])
- {
- [[self keyWindow] becomeMainWindow];
- }
}
else if ([self mainWindow] != nil)
{
@@ -1354,10 +1357,13 @@
_hidden_key = [self keyWindow];
[_hidden_key resignKeyWindow];
}
- // FIXME: main window is not saved for when the app is activated again.
- // This is not a problem if it is also key, and I'm not sure if it
- // is a problem at all. May be annoying in the case of workspace switch.
- [[self mainWindow] resignMainWindow];
+ // The main window is saved for when the app is activated again.
+ // This is necessary for menu in window.
+ if ([self mainWindow] != nil)
+ {
+ _hidden_main = [self mainWindow];
+ [_hidden_main resignMainWindow];
+ }
windows_list = GSOrderedWindows();
iter = [windows_list reverseObjectEnumerator];
Index: Source/NSSavePanel.m
===================================================================
--- Source/NSSavePanel.m (revision 31886)
+++ Source/NSSavePanel.m (working copy)
@@ -50,7 +50,6 @@
#import "AppKit/NSImage.h"
#import "AppKit/NSImageView.h"
#import "AppKit/NSMatrix.h"
-#import "AppKit/NSMenu.h"
#import "AppKit/NSPasteboard.h"
#import "AppKit/NSDragging.h"
#import "AppKit/NSSavePanel.h"
@@ -183,7 +182,6 @@
NSImage *image;
NSRect r;
id lastKeyView;
- NSInterfaceStyle style = NSInterfaceStyleForKey(@"NSMenuInterfaceStyle", nil);
// Track window resizing so we can change number of browser columns.
[[NSNotificationCenter defaultCenter] addObserver: self
@@ -375,12 +373,6 @@
[self registerForDraggedTypes: [NSArray arrayWithObjects:
NSFilenamesPboardType, nil]];
-
- if (style == NSWindows95InterfaceStyle)
- {
- [[[[NSApp mainWindow] menu] attachedMenu] close];
- }
-
return self;
}
Index: Source/NSMenuView.m
===================================================================
--- Source/NSMenuView.m (revision 31886)
+++ Source/NSMenuView.m (working copy)
@@ -1389,14 +1389,21 @@
- (BOOL) _executeItemAtIndex: (int)indexOfActionToExecute
removeSubmenu: (BOOL)subMenusNeedRemoving
{
+ NSInterfaceStyle style =
+ NSInterfaceStyleForKey(@"NSMenuInterfaceStyle", self);
+
+ /*If we have menu in window, close the menu after select
+ an option*/
+ if (style == NSWindows95InterfaceStyle)
+ {
+ [[[[NSApp mainWindow] menu] attachedMenu] close];
+ }
+
if (indexOfActionToExecute >= 0
&& [_attachedMenu attachedMenu] != nil && [_attachedMenu attachedMenu] ==
[[_items_link objectAtIndex: indexOfActionToExecute] submenu])
{
- NSInterfaceStyle style =
- NSInterfaceStyleForKey(@"NSMenuInterfaceStyle", self);
- if (style == NSMacintoshInterfaceStyle ||
- style == NSWindows95InterfaceStyle)
+ if (style == NSMacintoshInterfaceStyle)
{
// On Macintosh, clicking on or releasing the mouse over a
// submenu item always closes the menu (if it is open) and
@@ -1405,6 +1412,11 @@
return YES;
}
+ if (style == NSWindows95InterfaceStyle)
+ {
+ return YES;
+ }
+
if (subMenusNeedRemoving)
{
[self detachSubmenu];
Index: Headers/AppKit/NSApplication.h
===================================================================
--- Headers/AppKit/NSApplication.h (revision 31886)
+++ Headers/AppKit/NSApplication.h (working copy)
@@ -145,6 +145,7 @@
NSMutableArray *_hidden;
NSMutableArray *_inactive;
NSWindow *_hidden_key;
+ NSWindow *_hidden_main;
GSInfoPanel *_infoPanel;
/* This autorelease pool should only be created and used by -run, with
_______________________________________________
Gnustep-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnustep-dev
