[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #27088] Menu Appearance under NSWindows95InterfaceStyle
From: |
Chris Armstrong |
Subject: |
[bug #27088] Menu Appearance under NSWindows95InterfaceStyle |
Date: |
Thu, 14 Jan 2010 00:55:09 +0000 |
User-agent: |
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; en-US) AppleWebKit/532.5 (KHTML, like Gecko) Chrome/4.0.249.49 Safari/532.5 |
Follow-up Comment #2, bug #27088 (project gnustep):
I've been monitoring the latest changes to implement proper in-window menus,
where each window has its own menu. I've attached a patch that changes the
policy for where the main menu view is inserted. Instead of removing and
inserting the main menu view from the key window as it changes, we create a
new menu view for each window that responds YES to -[NSWindow canShowMenuBar].
This patch needs review, as:
* it changes the policy for how sub-menus are displayed transiently.
* it introduces a new public method to NSWindow for determining when a menu
view is created for a window
* the default policy for determining if a menu view is displayed in a window
is not sophisticated enough. It currently assumes that any window that can
become the main window is suitable: for example, the Info Panel will display
the menu bar.
* haven't tested code path in setMain:
* NSException raise at end of findMenuView should probably be an NSAssert
(file #19488)
_______________________________________________________
Additional Item Attachment:
File name: GNUstep-GUI-20100114-separate_in_menu_windows.diff Size:8 KB
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?27088>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
- [bug #27088] Menu Appearance under NSWindows95InterfaceStyle,
Chris Armstrong <=