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.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
