Created attachment 265315 [details] [review]
ShellTrayIcon: forward key presses too

StWidget::popup-menu is emitted when Menu/<Shift>F10 is pressed,
not released (for consistency with Gtk+), so we need to forward
that. Note that for key press we don't emit the matching key
release, because the app will take a grab and get the event directly
from X when the key is physicall released.

Review of attachment 265315 [details] [review]:

> Note that for key press we don't emit the matching key
> release, because the app will take a grab and get the event directly
> from X when the key is physically released.

There's no guarantee that they're going to pop open a menu or take a grab, so this could mess up the app's tracking. Which is really annoying. I can't think of a better way to fix this, though.

::: src/shell-tray-icon.c
@@ +191,1 @@
   ClutterEventType event_type = clutter_event_type (event);

I just noticed, but the doc comment for shell_tray_icon_click is completely outdated, and talks about how it must be a CLUTTER_BUTTON_RELEASE event. Updating this at the same time would be nice.

@@ +254,1 @@
       xkevent.keycode = clutter_event_get_key_code (event);

Can you reorder this so it's

  keycode = ...;

  type = KeyPress;
  XSendEvent (...);

  /* If the application takes a grab on KeyPress, we don't
   * want to send it a KeyRelease. There's no good way of
   * knowing whether a tray icon will take a grab, so just
   * assume it does, and don't send the KeyRelease. That might
   * make the tracking for key events messed up if it doesn't take
   * a grab, but the tray icon won't get key focus in normal cases,
   * so let's hope this isn't too damaging...
   */
  type = KeyRelease;
  XSendEvent (...);

Pushed with suggested changes. I will push to 3-10 too, up to downstreams
if they want to backport to 3.8

Attachment 265315 [details] pushed as 7d13cf1 - ShellTrayIcon: forward key presses too