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

 
 

You are not allowed to post comments on this tracker with your current authentification level.

bug #27088: Menu Appearance under NSWindows95InterfaceStyle

Submitted by:  Jonathan Gillaspie <jonathanosx>
Submitted on:  Thu 23 Jul 2009 06:18:42 PM UTC  
 
Category: Gui/AppKitSeverity: 3 - Normal
Item Group: BugStatus: None
Privacy: PublicAssigned to: None
Open/Closed: Open

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>
Project 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>
Project Member

 

Attached Files
file #19488:  GNUstep-GUI-20100114-separate_in_menu_windows.diff added by carmstrong (9kB - 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
  • -unavailable- added by carmstrong (Updated the item)
  • -unavailable- added by rmottola (Posted a comment)
  • -unavailable- added by jonathanosx (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 18 Jan 2010 10:36:23 AM UTCcarmstrongAttached File-=>Added GNUstep-GUI-20100118-separate_in_menu_windows.diff, #19512
    Thu 14 Jan 2010 12:55:09 AM UTCcarmstrongAttached File-=>Added GNUstep-GUI-20100114-separate_in_menu_windows.diff, #19488

    Back to the top


    Powered by Savane 3.1-cleanup