[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 06:23:20 +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 #3, bug #27088 (project gnustep):
Okay, further investigation would suggest that my patch is naive and not the
correct way to approach this problem. Because it breaks the assumption that
there is only one menuview per menu, the mouse tracking machinery in
-[NSMenuView trackWithEvent:] can't work correctly.
One specific case that exposes an issue is if the user moves the mouse into a
submenu of the horizontal window menu, and then tries to move back to the main
menu, the menu handling machinery does not close the submenu and highlight the
new submenu. Because trackWithEvent: works with the assumption that it can
find the ancestor menu view by traversing the NSMenu hierarchy, it can't find
the ancestor menu view as it is not associated with the main menu NSMenu
instance. We would need to modify display/displayTransient and trackWithEvent:
to use a stack of the relevant NSMenuView instances to find the way back to a
ancestor NSMenuView if the user moves the mouse cursor back into a
higher-level menu.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?27088>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/