That I would actually prefer. Those items could be hidden, but especially activated when the context makes sense for it.
The current situation is unsatisfactory for new users Am Di., 27. Aug. 2019 um 22:45 Uhr schrieb Guy Harris <g...@alum.mit.edu>: > On Aug 27, 2019, at 1:14 PM, Roland Knall <rkn...@gmail.com> wrote: > > > I have a short question. While refactoring the Apply/Prepare menu (due > to quite a few issues with enabling/disabling), I stumbled across the items > "Copy as Filter", "Expand subtree", "Collapse subtree", and similar items. > > > > I am wondering, if it makes sense to have those in the main menubar. > > For what it's worth: > > * The Apple UI guidelines say > > Always make contextual menu items available in the menu bar too. A > contextual menu is hidden by default and a user might not know it exists, > so it should never be the only way to access a command. In particular, > avoid using a contextual menu as the only way to access an advanced feature. > > See > > > https://developer.apple.com/design/human-interface-guidelines/macos/menus/contextual-menus/ > > * The KDE UI guidelines say > > Don’t use context menus as the only way to access functionality. > Every item in a context menu must be available via a method that is somehow > visible by default–typically the app’s main menu bar, but also via toolbar > buttons. > > See > > https://hig.kde.org/components/navigation/contextmenu.html > > * The Windows UI guidelines don't discourage context menus; what they do > say is: > > Do the following conditions apply: > > * Is there a small set of contextual commands and options > that apply to the selected object or window region? > > * Are these menu items redundant? > > * Are the target users familiar with context menus? > > If so, consider providing context menus for the objects and window > regions that need them. > > See > > https://docs.microsoft.com/en-us/windows/win32/uxguide/cmd-menus > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
