MenuBar: implement

[bill]

Implement MenuBar. Although you can get a MenuBar by using Toolbar but there are some issues with it; it doesn't quite work like menu. And it seems like a lot of people are asking for a real MenuBar. See http://dojotoolkit.org/forum/support/dijit/menubar .

From that post:

Leaving Menubar out of Dijit really feels like a mistake... It's not just a matter of using a Toolbar and DropDownButtons. That combination doesn't work the way menus work:

1. You can't navigate left and right using arrows;
   
2. you have to release the mouse button before the menu appears;
   
3. the menu doesn't quite line up with the button;
   
4. the overall menu structure isn't represented as such for accessibility.
   

[guest]

Is this still on? Would love to have it! /Max

[bill]

Hi, still definitely planning to do it; not sure if it will make it for 1.1 though.

[guest]

More Requirements:

1.) When clicking on a menu (say File), and then hovering over another menu (say Edit), the File menu should close and the edit should open with no additional click. The toolbar menu is "open" once one child has opened. This behavior is easily seen in the dijit.Toolbar test (with drop down buttons).

2.) Fudge factor for popup. If you click a popupmenu(submenu) and then diagonally slide your mouse, there should be a small timeout to allow you to get into the submenu without it disappearing. If you try the "history" menu in firefox, hover over "recently closed tabs" and sort of go down and to the right to get into the large list. It hangs out for a second, allowing you to get in there. Dojo menus go down unless you keep your mouse entirely in the parent menu item the whole time. This makes for a squirrely menu.

[bill]

You've cut and paste the above comment from #6773. #1 is the main point of having a MenuBar widget, and #2 is already listed in #6773.

[dante]

i've run out of 1.2 time ...

[dante]

... taking a new interest in this.

[David Schwartz]

• Can the menu bar be used to implement a left-hand nav system?
  

• Is the visual design driven entirely by .css?
  

• Can the bar be oriented vertically?
  

• If vertically oriented, will the menus display along the trailing edge (right side for English systems)?

[bill]

bumping 1.4 tickets to 1.5, and most 1.3 tickets to 1.4

[bill]

Replying to drschwartz:

• Can the menu bar be used to implement a left-hand nav system?
  

• Can the bar be oriented vertically?
  

No... I've broken out that request into #8316

• Is the visual design driven entirely by .css?
  

No, unfortunately it involves HTML changes too... using a <table> vs. a <span> In the vertical case each MenuItem is a <tr>, but not so for the horizontal case.

• If vertically oriented, will the menus display along the trailing edge (right side for English systems)?

Yes, when #8316 is implemented that's how it will work.

[bill]

Implemented in [16134], [16136], [16138], [16139], and [16141].

[liucougar]

(In [16187]) fixes #8326: this happens to fix a request on #4634 (refs #4634) as well !strict

[bill]

(In [16233]) Defer focusing on a static Menu/MenuBar? until user clicks it, or tabs into it. Once user clicks on a Menu/MenuBar?, it focuses on it, and then (as before) any mouse movement or keyboard movement (via arrow keys) will change focus. Also (as before), focus is shifted to a context menu immediately when it's displayed.

Separated out CSS classes for indicating that a MenuItem? is mouse hovered (dijitMenuItemHover), and to indicate which MenuItem? is selected/active (dijitMenuItemSelected). Currently they look exactly the same, although that could be changed (including removing the hover effect altogether).

"Selected/active" is in the sense of the selected tab, and is controlled by the mouse or keyboard. Implementation-wise, it means that either the MenuItem? has focus, or focus is on a submenu of that MenuItem?.

Also added dijitMenuPassive/dijitMenuActive class to the Menu/MenuBar? domNode so that CSS rules for hover can be customized based on whether or not the menu has focus. Once the menu gets focus the dijitMenuHover effect is disabled in favor of the dijitMenuSelected effect, so that the dijitMenuHover effect won't linger on "File" if user moved the mouse over "File" but then used the keyboard arrows to move to the "Edit" MenuBarItem?. (This is a setting in tundra/nihilo/soria and can be changed if desired.)

Open issue with re-focus on click-execute of a leaf menu item... after executing a menu choice focus ends up nowhere (or maybe on the page itself). Probably should be going to the menubar?

Refs #4634 !strict

[liucougar]

(In [16237]) refs #4634: added an extra span within MenuBarItem? so that disabled item should up properly don't open a disabled item's popup when changing focus from an item with popup opened added a disabled MenuBarItem? to test page

[bill]

(In [16248]) Split Menu templates into separate files. Refs #4634 !strict

[bill]

(In [16249]) Rename MenuBarItem? to PopupMenuBarItem? (analgous to PopupMenuItem?), and make MenuBarItem? as simple clickable no popup MenuBarItem?. Refs #4634 !strict

[bill]

(In [16250]) More separation of templates out into separate files. Refs #4634 !strict

[bill]

(In [16251]) Remove arrow icon from CheckedMenuItem? template; it doesn't make sense since that's always a leaf node. Also, simplified templates to use <img> tag rather than <div> tag for images, as per dijit standard. Refs #4634 !strict