[Roland Knall <rknall@xxxxxxxxx>]

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 <guy@xxxxxxxxxxxx>:

On Aug 27, 2019, at 1:14 PM, Roland Knall <rknall@xxxxxxxxx> 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@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe