EFL/Wayland and xdg-shell
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
More information about the wayland-devel