Thoughts on getting surfaces to appear on the right output

[Bill Spitzak]

Two comments on the proposal:

1. It would seem more useful for the desktop shell to send some info 
about how the client was launched in environment variables. The client 
may want to do other reactions besides just placing it's window, and 
this will work for clients that do not want to use the socket (such as a 
client that wraps a launch of a remote client?).

2. If the desktop shell creates the socket, there is no need for it to 
"send commands" on it. Instead it can directly manipulate the local end 
to have the results of those commands.

I also want to rant about "getting surfaces to appear on the right 
output" which is currently impossible on Wayland, even if the above 
fixes are added:

The apps I am working on control multiple-window clients on multiple 
outputs. There is at least one full-screen window, and then several 
large (but not full-screen) windows arranged on the remaining outputs. 
Sometimes all outputs are filled with fullscreen windows, and also 
sometimes some of these are maximized instead of fullscreen (to make it 
possible to hit the titlebar button to toggle screen-filling on/off, and 
also because of important information that is displayed in the titlebar 
(that may be a bad idea, but it is there...). See Nuke for an example, 
if users have multiple outputs they usually put a viewer on one output 
and put all the controls (a big tiled window) on the other output. Most 
clients have a significant difference between the outputs (only one is 
calibrated, or one is the big-screen on the wall that their customers 
see, etc).

In any case our users expect to get exactly the same layout they arrived 
at before when they run the software again. Wayland is not delivering 
this, instead every window lands on the same output. Even if it tried to 
intelligently place them on "unused" outputs it is not going to work, we 
had some window managers that did this and they would randomly swap 
which window was on which output, and that is definately not what the 
user wants.

I know it is rejected, but I also have to point out that EVERY OTHER 
SYSTEM uses an x,y position in a huge plane where all the outputs are 
mapped to non-overlapping rectangles to determine which output a window 
appears on. This x,y position can both be read and set by a client, and 
the client can then save it in a configuration file as two numbers per 
window. Wayland is breaking this: first we do not have the level of 
control we have in other systems, but much more serious is we do not 
have cross-platform savable configurations (and many of our users 
actually do reboot to swap between Linux and OS/X).

On 05/02/2014 11:22 AM, Neil Roberts wrote:
> launches. To do this I was thinking that maybe desktop-shell could make
> a connection to the compositor on behalf of the client, call a request
> to set the default output and then pass the socket down to client using
> the existing WAYLAND_SOCKET mechanism.