new xwayland protocol

[Bill Spitzak]

William Swanson wrote:
> On Fri, Sep 14, 2012 at 12:01 PM, Bill Spitzak <spitzak at gmail.com> wrote:
>> Both Linux and windows support text files that say something like this (we
>> wrote the code that reads/writes these files):
>>
>>   window_position: 10,30,400,500
> 
> Your example is already deeply broken, since it doesn't consider
> things like the current virtual desktop, the minimization/maximization
> state, z-order, zoom level, rotation, 3D positioning, window roll-up
> or a host of other issues that may or may not be relevant depending on
> the current window manager / compositor.

Actually it does save the fullscreen/maximized/iconized state, that was 
a simplified example. It does not save the Z because X does not support 
setting that (and users expect the new windows on top). And it does not 
store the virtual desktop because of a combination of non-use by our 
users and I also think they expect new windows to appear on the current 
desktop always.

> When you really step back and think about it, why duplicate the same
> position-saving code again and every app? Why not let the compositor
> handle this? After all, the compositor is the one program that is
> actually knows what's relevant and what is not.

The main problem is that this text is saved in a file along with a huge 
amount of very app-specific code. So the api that is really needed is to 
return a string that we can write ourselves to a file, and another api 
to interpret this string. The problem here is you cannot stop apps from 
parsing this string to extract info they want, and thus you may end up 
with an undocumented x/y position api that you have to support.

Another big concern is that complex popup menu systems rely on accurate 
positioning of the menu windows and knowledge of the obscured area. This 
sounds like the reason xserver needs this information. A common example 
is hierarchial popup menus where the submenu may popup to the left, 
along with different graphics in the parent menu, if the normal location 
to the right is obscured. It is also needed to correctly support 
floating toolbox windows and dialogs (these are broken in X/Windows but 
it is a huge hope Wayland will fix this by removing click-to-raise).

The current wayland api to automatically move windows into the 
unobscured area is not usable for this. I don't see any way to do this 
unless subwindows at least have accurate x/y positions or transforms 
relative to the parent. It then makes sense to have a transform for the 
parent so the api is consistent. I can also imagine a rather painful 
amount of rewrite if the obscured region is per-window rather than a 
global region with the windows positioned in it.

Apps also want to draw pictures of the monitor layout and thus need the 
xy position of monitors.