|
From: | Fred Kiefer |
Subject: | Re: [Gnustep-cvs] r33837 - in /libs/gui/trunk: ChangeLog Source/GSThemeMenu.m |
Date: | Tue, 20 Sep 2011 22:50:48 +0200 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.2.22) Gecko/20110907 SUSE/3.1.14 Thunderbird/3.1.14 |
On 20.09.2011 19:27, Germán Arias wrote:
This works with the exception that the horizontal menu don't track the mouse when the user return from a submenu. This is because now we cant access the menu representation with [menu menuRepresentation]. So for
Yes, that was the problem I was refering to in my mail.
the moment, I have something like this at line 1687 in NSMenuView.m: NSEnumerator *e = [[[mainWindow _windowView] subviews] objectEnumerator]; NSView *v; NSMenuView *mainWindowMenuView; while ((v = [e nextObject]) != nil) { if ([v isKindOfClass: [NSMenuView class]] == YES) { mainWindowMenuView = v; break; } } But I think maybe is better add the _menuView variable in NSWindow (no retained) and methods -menuView and -setMenuView. So we can access easily the menu representation.
I would rather like to add a method -menuView to the GSWindowDecorationView, which is a GNUstep private class. We should not mess around too much with official classes.
In this specific case it may even be better to rearrange the code a bit. Are we expecting for this code to work between different windows? I don't think so. So why not pass on the original menu view when calling _trackWithEvent:, just as we do with the event? And even another step better would be to completely rewrite this method to get rid of all these calls to the [menu window] and the like...
[Prev in Thread] | Current Thread | [Next in Thread] |