Vincent van Ravesteijn <v.f.vanraveste...@tudelft.nl> writes: > This patch disables all submenus in the menu bar that have no enabled > items.
This is something I have not done until then because the HIG are not very clear... * Apple HIG states: Even if all of the items in a menu or submenu are unavailable, the menu or submenu title is not dimmed. The user can still open the menu, but all of its items are dimmed to indicate that these items are not available in the present context. Figure 13-13 shows a menu with unavailable menu items in the open and closed state. http://developer.apple.com/documentation/UserExperience/Conceptual/AppleHIGuidelines/XHIGMenus/chapter_17_section_2.html#//apple_ref/doc/uid/TP30000356-TPXREF119 * The Vista User guide seems to say that the current solution ("No Document Open") is the right one (although I am not sure I agree). Given the need for learning and discoverability, users expect menu bars to be stable. That is, users expect to see the same menu items as they did the last time they used the menu. The menu items can be enabled or disabled based on the current context, but menu items or submenus shouldn't be added or removed. However, you may add or remove entire menu categories based on obvious changes in program state (such as a document being loaded). That said, disabled menu items can be confusing because users have to determine why the item is disabled. If the reason isn't obvious, users have to determine the problem through experimentation and deductive logic. In such cases, it's better to leave the item enabled and give a helpful error message to explain the problem explicitly. http://msdn.microsoft.com/en-us/library/aa511501.aspx * The KDE and Gnome guides do not say anything about submenus. Solutions I see: 1/ disable the menu only if it is empty (and apply Vincent's patch to remove 'No Document Open' entries). 2/ gray out the submenu but keep it openable so that people can see why the menu cannot be open. I am not sure that the mighty Qt would allow us to do that, though. In this case, we should keep the 'No Document Open' messages. 3/ stay as we are (which may be a good enough workaround for 2/) If we keep the 'No Document Open' messages, I think we should move them to be an argument to the dynamic-menus generating commands, like: Toc "No Document Open" This would avoid to hardcode the strings and also allow us to pass an empty string (do not insert an entry if empty) if we do not want a message or if we want a more meaningful one (in the navigate menu, for example). In any case, we probably should get rid of the OptSubMenus (maybe too unintuitive): it is nice to see where a menu /should/ be, even it one cannot select it. JMarc
