[enhancement] Missing a generic API for child surface placement

[Daniel van Vugt]

Mir is missing a generic API for child surface placement. That is "put child surface at x,y relative to parent".

The approach we've taken so far (MirRectangle/MirEdgeAttachment) doesn't work for the windowed XMir case. In X, a menu is just a window with some relative placement x,y. There is no surface "type" (at least during creation) to base placement rules on. See:
  http://tronche.com/gui/x/xlib/window/XCreateWindow.html

But "menu" is not the only use case. In X everything is just a generic window by default. So Mir needs some typeless client API that doesn't enforce WM semantics to support a windowed XMir. Also, when this exists, the MirRectangle/MirEdgeAttachment APIs will be redundant.

[Daniel van Vugt (vanvugt)]

Hmm... we could fake an adjacency rectangle of size 0,0 and position x,y. That might work, but still nothing coming from Xmir will be type "menu".

[Gerry Boland (gerboland)]

For Qt we're (ab)using the current API just as you said, with the zero sized adjacency rect with x,y set. Qt doesn't have support for this adjacency rectangle concept. Instead to decide menu position on X, it reads the screen size and the parent window position on the screen, and uses that data to decide where the menu should be placed (to stop it going off screen for example)

[Chris Halse Rogers (raof)]

It's perfectly possible to get type menu out of XMir - you just map everything marked override-redirect as a menu.

[Daniel van Vugt (vanvugt)]

"Override redirect" doesn't mean menu. It can mean any window type that shouldn't get default decorations. Including tooltips. In the weirdest cases, override redirect is used for shaped splash screens at the start of games (wine games I recall?).

I now remember a "menu" is indicated by atom _NET_WM_WINDOW_TYPE == _NET_WM_WINDOW_TYPE_*MENU [1]
But the important thing to keep in mind is that this atom doesn't exist during window creation. It gets attached afterwards. So we need to do a generic Mir surface create, and then might get a mir_surface_set_type(s, menu) soon after from XMir.

[1] http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472629520

[Daniel van Vugt (vanvugt)]

On second thoughts, we can probably avoid needing mir_surface_set_type if XMir defers surface creation till XMapWindow. By that time it's likely the toolkit will have set _NET_WM_WINDOW_TYPE if it is going to at all.

[Chris Halse Rogers (raof)]

Right. The last time I touched XMir it did indeed defer surface creation until the RealizeWindow hook, which is called in response to XMapWindow.

[Daniel van Vugt (vanvugt)]

I have found some awkward ways to work around this problem in Xmir (in most cases) and implement positioning for some sub-surfaces using the existing Mir client API:
  https://git.launchpad.net/~xmir-team/xorg-server/+git/xmir/

Turns out I forgot a more significant annoyance of X apps -- that is their menus and dialogs etc are parented by the root window. So in order to find the related app window you need to use the WM_TRANSIENT_FOR property. That works for modern toolkits running under X, just not pure legacy X apps that draw their own menus override redirect (try 'bitmap').

So we've now got a hack that mostly works in Xmir without any enhancement to Mir required.