Make new onmouseover submenus real menus

[ghost]

This is the same issue as #14, this time applying to the new submenus in beta Steam client. Hovering over a menu header and having the submenu displayed causes main window to lose focus, since the submenu is a full-fledged separate X window, instead of a proper menu.

Same applies to right-click menu in any part of the main window, should I open a separate issue for that? It's probably the same underlying problem.

Come on, guys, you can do Store page popups right, why not fix the rest?

[gdrewb-valve]

This is a duplicate of #14, as all menus in the Steam client that aren't from web pages are done in the same way. The Steam client (not the WebKit-driven web content like the store) is a regular X application and the normal way to do menus in X is create a new window. We set the appropriate property indicating it's a menu window; if you think we aren't setting the right properties on the menu window we can look at that. If the request is just to stop using X windows then it's not going to happen any time soon since that's a fundamental change in the way the Steam client does its GUI.

[ghost]

No, of course I do not want you to stop using X windows. However, I do not think Steam is creating proper menu-type and popup-type windows (I am not that well versed in low-level X protocol, so my terminology might be off).

To begin with, I have my window manager (kwin from KDE 4.9) configured so that it makes windows without focus partly transparent, so I can easily see where the focus is. Now, Take for example any random GTK+ or Qt application: a menu doesn't take focus away from the parent window. Parent window remains 100% opaque, whereas the newly appeared menu is partly transparent, even if mouse cursor is over it, and let's say moving over various menu items.

When I do the same in Steam, the parent window loses focus and becomes partly transparent. This happens with any right-click menu, as well as with the new submenus in recent Steam beta. It also happens with most popups, where I noticed it first - hence issue #14.

I tried capturing window properties for the menus using xprop tool, but I can't even launch xprop when a GTK+ menu is displayed (error message suggests it can't capture the mouse), but I can launch xprop when a Steam menu is displayed. The properties dump suggests that window type is indeed set correctly, but as I have nothing to compare it against (can't get this dump for other widget toolkits' menus), I can't tell what's missing.

I do not know what Steam is doing wrong here, but something definitely is wrong.

[gdrewb-valve]

You point out what GTK+ and Qt are doing differently from Steam: they aren't giving the menu focus. As you mention their menus do not go to 100% opaque because it doesn't have focus. Steam does give its menu focus because that's where keyboard input will go, so having it go 100% opaque (and the main client not) is an accurate indicator of what will process keyboard activity.

It would be possible for the Steam client to change to not give focus to menus, but it seems correct that the thing which wants key input should have focus. Why is the menu getting focus a problem? When the menu goes away the main client should get focus back, is that working properly?

[ghost]

The thing is that even Steam menus and popups are not 100% opaque when they appear. And yes, sometimes the focus doesn't come back to the main window, but stays "in limbo", where I can't even alt+tab between windows (but that's probably out of scope here, and for all I know problem might be in kwin).

Meanwhile, I read a bit about _NET_WM_WINDOW_TYPE hint, and discovered that according to latest freedesktop.org wm-spec draft[1], Steam is not setting correct type. xprop shows that Steam's menus have _NET_WM_WINDOW_TYPE_MENU type, which should be used for torn-off, separately managed menus. A more proper type is probably either _DROPDOWN_MENU or _POPUP_MENU. (And _POPUP for popups from issue #14. :) )

These are not present in version 1.3 of the same spec, but even though 1.4-draft.2 seems to be a draft, it is several years old, and at least GTK+ (both 2.x and 3) seems to be following it[2]. I did not dig deep enough to see if it really is currently accepted spec, but it seems so.

1. http://standards.freedesktop.org/wm-spec/1.4/ar01s05.html#id2747194
2. https://developer.gnome.org/gdk2/stable/gdk2-Windows.html#GdkWindowTypeHint

[gdrewb-valve]

We can't distinguish popup from dropdown_menu from popup_menu as they're all the same inside of Steam at the level where it's setting X properties, so I don't know that we can be more sensible about setting the window type. I'll leave this issue open to look into that, but it'll be more of a long-term item.

[ghost]

Thank you. I agree that it's not a show-stopper, but it makes Steam look somewhat clunky among other applications in a modern desktop.

[malysps]

Any news about this issue? I've made a short video to show you how it looks in Avant Window Navigator and default "window buttons" plug-in on the Xfce 4.12 panel. It's very distracting and I agree with ticho: "it makes Steam look somewhat clunky among other applications in a modern desktop"

https://drive.google.com/open?id=0B8qh4-wxxEZ7T2NpUHUzWXZRUlk