Panel menus/applets should present consistent behaviour

[Paul Sladen]

Binary package hint: gnome-panel

A menu bar has the following behaviour:

  1. Click to activate
  2. Move around (close menu/sub-menu will open/collaspse as required for duration)
  3. Click to deactive

Cruically nothing _happens_ until a further click/keypress has occured. The behaviour of the gnome-panel at the top of the screen is highly inconsistent, unpredictable and only curtain sections behave like a menu. Currently I have the following applets:

  a. Applications/Places/System (behaves like a menu, within itself) -- 3x Tooltips (two-step action)
  b. Firefox, "?", VNC launcher applets (immediate response, click to active, differentiated by a slight 3D effect, hover effect) -- 3x Tooltips (immediate action)
  c. Network Monitor (broken gradient) click brings up error dialogue SIOCGIFFLAGS error -- Tooltip (status)
  d. Weather (Click brings up dialogue) -- Tooltip (status)
  e. Search entry (Click shows non-standard "menu" within input box, but reclick does not release) -- highlighted -- Tooltip (delayed action)
  f. Spacer (Click+drag moves) -- no Tooltip
  g. Bluetooth (Menu) -- no highlight -- no tooltip
  h. Network Manager (menu, but opens in opposite direction) -- no highlight -- Tooltip (Status)
  i. Battery (Menu with status information) -- no highlight -- no Tooltip
  j. Date (Menu picture box) -- hover -- highlight -- Tooltip (action starting with "Click to...")
  k. Me/Shutdown (behaves like a menu, within itself) -- no tooltip

There are two main predictable behaviours in the above, all of the rest are "special" and unpredictable:

  1. Menus: Only the Applications+Shutdown menu groups behave consistently, and these do not share "menu state"; one has to be explicitly close behave hover navigation on the second works. (No hover, non-destructive actions, no input or status in menus, except as radio groups, further choices end with "...")
  2. Buttons (Launchers): Hover effect, tooltip, and semi-immediate action (moving off with click held down cancels)

The other applets all have special, non-predictable behaviour. Ideally all should be aligned to one of the two classes, and those classes made consistent within themselves (eg. menus should not have tooltips, and buttons should always have tooltips). The only input allowable in menus should be choices ("selecting from a menu").

Tooltips on buttons should not start "Click to" as this is presumptive and unnecessary. The same "More action required ..." ellipsis should be used in tooltips for actions requiring further choices (non-immediate).

[Sebastien Bacher (seb128)]

don't create a bug with tasks on different components this way you will bugspam subscribers to any of those

[Matthew Paul Thomas (mpt)]

We are gradually fixing this with our status menus in indicator-applet. <https://wiki.ubuntu.com/CustomStatusMenuDesignGuidelines>

For the reason Sebastien gave, it is counterproductive to have a single report covering different fixes to unrelated packages. Use a single bug report only if the patch that fixes a bug in one place is likely to be reusable to fix it in another place, or if the nature of the bug requires that multiple packages be changed near-simultaneously. Neither are true here.