bugGNUstep - Bugs: bug #27088, Menu Appearance under...

Group
 
 

bug #27088: Menu Appearance under NSWindows95InterfaceStyle

Submitter:  Jonathan Gillaspie <jonathanosx>
Submitted:  Thu 23 Jul 2009 06:18:42 PM UTC
   
 
Category:  Gui/AppKit Severity:  3 - Normal
Item Group:  Bug Status:  Fixed
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Thu 23 Oct 2014 08:45:28 AM UTC, comment #5: 

There have been several improvements in in-window menus. First there were fixed, then we also stopped migrating menus. Could the original poster see if the behaviour is now better for him?
Especially on Windows with native menus they work quite reliably.

Riccardo Mottola <rmottola>
Group Member
Mon 18 Jan 2010 10:36:23 AM UTC, comment #4: 

Ok, worked on this a bit more. Attached is a patch that implements proper menu opening and closing. The main remaining problems are:
1. If the user decides to click on a non-GNUstep window to stop the menu loop, the menus get stuck.
2. User can change focus and drag around windows without the menu loop being aborted.

I think the main solution to these problems is to cause the menu loop in -[NSMenuView trackWithEvent:] to be aborted if the mouse is clicked on a title frame or outside the GNUstep windows.

The patch probably needs review, because the way it achieves what it does is a little weird.

(file #19512)

Chris Armstrong <carmstrong>
Thu 14 Jan 2010 06:23:20 AM UTC, comment #3: 

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.

Chris Armstrong <carmstrong>
Thu 14 Jan 2010 12:55:09 AM UTC, comment #2: 

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)

Chris Armstrong <carmstrong>
Fri 24 Jul 2009 10:55:45 AM UTC, comment #1: 

This problem has been discussed at FOSDEm already. I guess part of the problem is also deciding which window is "key" and what happens on the other window.

If I try Ink on windows I notice the following.

One document only, I have a nice menu inside the window.

I make "new" and the new window takes the menu, the old one looses it and it remains only with an empty window (from windows, a window with no frame, only title)).

Clicking back and forth between  the two windows doesn't move the menu. So The behaviour is not only strange, but broken. Closing the second window doesn't bing the menu back to the first, but makes it appear on top like it was mac-style

Riccardo Mottola <rmottola>
Group Member
Thu 23 Jul 2009 06:18:42 PM UTC, original submission:  

First off let me say that I'm really impressed and excited about the new default for
    NSMenuInterfaceStyle NSWindows95InterfaceStyle

That said, it has a few peculiarities/bugs that prevent us from using it in production.
The first is that the menu seems to follow the key/active window and disappear from other windows.

I personally think it would be better for it to be ever-present on the windows it will be on; if there is a desire for both behaviors maybe we could have two interface styles.  But always present is how a typical Windows (or Linux) application would work - not having it appear and disappear.

If it IS going to continue to come and go then there is a definite bug with redrawing when it appears on a window with a toolbar, the toolbar items don't seem to redraw in the new location.

Jonathan Gillaspie <jonathanosx>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #19488:  GNUstep-GUI-20100114-separate_in_menu_windows.diff added by carmstrong (9KiB - application/octet-stream - Implement one drop-down menu per window. Needs review.)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by gcasa (Updated the item)
  • -email is unavailable- added by carmstrong (Updated the item)
  • -email is unavailable- added by rmottola (Posted a comment)
  • -email is unavailable- added by jonathanosx (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-10-30 gcasa StatusNone Fixed
        Open/ClosedOpen Closed
    2010-01-18 carmstrong Attached File- Added GNUstep-GUI-20100118-separate_in_menu_windows.diff, #19512
    2010-01-14 carmstrong Attached File- Added GNUstep-GUI-20100114-separate_in_menu_windows.diff, #19488

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code