EFL/Wayland and xdg-shell

Bill Spitzak spitzak at gmail.com
Wed Apr 15 18:21:32 PDT 2015


On 04/15/2015 03:51 PM, Carsten Haitzler (The Rasterman) wrote:

> i was thinking a simplified geometry. then again client toolkits can figure
> that out and present a simplified enum or what not to the app too. but yes -
> some enumerated "type" attached to the output would be very nice. smarter
> clients can decide their intent based on what is listed as available - adapt to
> the situation. dumber ones will just ask  for a fixed type and "deal with it"
> if they don't get it.
>
> well the problem here is the client is not aware of the current situation. is
> that output on the right a tv on the other side of the room, ore a projector, or
> perhaps an internal lcd panel? is it far from the user or touchable (touch
> surface). if it's touchable the app may alter ui (make buttons bigger - remove
> scrollbars to go into a touch ui mode as opposed ro mouse driven...). maybe app
> is written for multitouch controls specifically and thus a display far from the
> user with a single mouse only will make the app "useless"? app should be able
> to know what TYPE of display it is on - what types are around and be able to
> ask for a type (may or may not get it). important thing is introducing the
> concept of a type and attaching it to outputs (and hints on surfaces).

Another reason for the client to know the "type" is so it can remember 
it and use it to place a window later.

For instance the user may move the window to where she wants it and then 
do a "remember where the window is" command to the client. Then when the 
client is run next time, it puts the window on the same output as 
before. So the client must be able to query the type of the output the 
surface is on. For I hope obvious reasons it is not acceptable for the 
user to have to choose the "type" manually, thus there has to be a query 
to determine the type of the output a surface is on.

This may also mean that all outputs have to produce a different "type" 
(ie if the user has two projectors they are not going to be happy if 
software can't remember which, so they must be different "type" values), 
and there have to be rules for matching types (so if it is run on a 
system with only one projector then both types end up on that one 
projector).


More information about the wayland-devel mailing list