new xwayland protocol

[Bill Spitzak]

Pekka Paalanen wrote:

>> What is going to happen is Wayland clients are going to use the X api 
>> just to get this information.
> 
> No, that is impossible.

I do believe it will be impossible to use the Wayland API and be able to 
set window x/y positions by somehow messing with the X api. My worry is 
that clients will actually skip using Wayland and use X just because it 
gives them this ability.

>> I can tell you right now that our own 
>> software is not going to be usable unless we can save window layouts, 
> 
> Saving layouts will be solved differently than in X.
> 
>> and we are interested in portability to Windows and OS/X where the way 
>> to place windows on various outputs is to use the coordinates, not an id 
>> for the output.
> 
> I don't understand what you mean by portability here. You cannot run an
> X app in Windows without an X server, either.

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

It is true that after this file is parsed different calls are used for X 
and Wayland and WIN32. But at the moment both X and WIN32 have calls 
that take two integers called the x and y position, making this 
portable. The lack of this on Wayland is a problem.

The best I can do with Wayland right now is make up an x/y position 
based on the upper-left corner of the output the window is on (at least 
I believe this info is available). Another alternative is to write the 
output name to the file and do the translation on the Windows and Xlib 
backends, but I very much doubt that idea will be accepted.

> Apparently you have forgot all about, say, dome projectors or virtual
> displays, where the output is a half sphere. Good luck mapping Cartesian
> global coordinates there in any meaningful way.

Seems like there are two coordinates of finite range, thus fitting into 
a rectangle that can be made to not overlap the rectangles for any other 
output. For instance you could use a square where .5,.5 is the north 
pole, and the four sides are tangent to the equator. You could also use 
cylindrical coordinates where there is a square and one edge is the 
equator, one edge is scaled to 0 length at the pole, and the two other 
edges touch.

The only requirement for the transformation from window to screen is 
that a unique transformation is chosen for a given x/y position and 
window size. There is no need for it to be affine.

If you had a display that was actually a 3D volume, so that there are 
more than 2 independent coordinates, then I could see a problem. I don't 
think we need to worry about that just yet, however.