EFL/Wayland and xdg-shell

[Jasper St. Pierre]

On Mon, Apr 13, 2015 at 5:02 PM, Bryce Harrington <bryce at osg.samsung.com> wrote:
> A couple weeks ago I gave a talk on Wayland to the EFL folks at the
> Enlightenment Developer Day in San Jose.  They've already implemented a
> Wayland compositor backend, so my talk mainly speculated on Wayland's
> future and on collecting feature requests and feedback from the EFL
> developers.  Below is my summary of some of this feedback; hopefully if
> I've mischaracterized anything they can jump in and correct me.
>
>
> For the presentation, I identified Wayland-bound bits currently
> gestating in Weston, listed features currently under review in
> patchwork, itemized feature requests in our bug tracker, and summarized
> wishlists from other desktop environments.  Emphasis was given to
> xdg-shell and the need for EFL's feedback and input to help ensure
> Wayland's first revision of it truly is agreed-on cross-desktop.
>
>
> Considering KDE's feedback, a common theme was that xdg-shell should not
> get in the way of allowing for advanced configuration, since
> configurability is one of that D-E's key attributes.  The theme I picked
> up talking with EFL emphasized being able to provide extreme UI
> features.  For them, the important thing was that the protocol should
> not impose constraints or assumptions that would limit this.
>
> For purposes of discussion, an example might be rotated windows.  The
> set geometry api takes x, y, height, and width.  How would you specify
> rotation angle?

I'm confused by this. set_window_geometry takes an x, y, width and
height in surface-local coordinates, describing the parts of the
surface that are the user-understood effective bounds of the surface.

In a client-decorated world, I might have shadows that extend outside
of my surface, or areas outside of the solid frame for resizing
purposes, but these should not be counted as part of the window for
edge resistance, maximization, tiling, etc.

So, if I have a surface that is 120x120 big, and 20px of it are
shadows or resize borders, then the client should call
set_window_geometry(20, 20, 100, 100)

Additionally, the size in the configure event is in window geometry
coordinates, meaning that window borders are excluded. So, if I
maximize the window and get configure(200, 200), then I am free to
attach a 300x300 surface as long as I call set_window_geometry(50, 50,
200, 200).

If the compositor rotates the window, the window geometry remains the
same, but the compositor has the responsibility of properly rotating
the window geometry rectangle for the purposes of e.g. edge
resistance.

So, if I have a window with a window geometry of 0,0,100,100, and the
user rotates it by 45 degrees, then the effective window geometry the
compositor snaps to -42,-42,142,142. Correct me if my high school trig
is wrong :)

The window is never aware of its local rotation transformation.

Does that make sense? Is this not explained correctly?

> While window rotation was used more as an example of how built-in
> assumptions in the API could unintentionally constrain D-E's, than as a
> seriously needed feature, they did describe a number of ideas for rather
> elaborate window behaviors:
>
>   * Rotation animations with frame updates to allow widget re-layouts
>     while the window is rotating.

Why does xdg-shell / Wayland impede this?

>   * Arbitrary shaped (non-rectangular) windows.  Dynamically shaped
>     windows.

I don't understand this. Any shape always has an axis-aligned bounding
box. Using ARGB8888, you can craft windows of any shape.

>   * Non-linear surface movement/resizing animations and transition
>     effects.

Why does xdg-shell / Wayland impede this?

> There was lots of interest in hearing more about Wayland's plans for
> text-cursor-position and input-method, which are necessary for Asian
> languages.  A particular question was how clients could coordinate with
> the virtual keyboard input window so that it doesn't overlay where text
> is being inserted.  Security is also a top concern here, to ensure
> unauthorized clients can't steal keyboard input if (when) the virtual
> keyboard client crashes.

The solution GNOME takes, which is admittedly maybe too unrealistic,
is that IBus is our input method framework, and thus our compositor
has somewhat tight integration with IBus. I don't think input methods
need to be part of the core Wayland protocol.

> Regarding splitting out libweston, they suggested looking if a
> finer-grained split could be done.  For example, they would be
> interested in utilizing a common monitor configuration codebase rather
> than maintaining their own.  OTOH, I suspect we can do a better
> (simpler) API than RANDR, that doesn't expose quite so many moving parts
> to the D-E's, which may better address the crux of the problem here...
>
> One area we could improve on X for output configuration is in how
> displays are selected for a given application's surface.  A suggestion
> was type descriptors for outputs, such as "laptop display",
> "television", "projector", etc. so that surfaces could express an output
> type affinity.  Then a movie application could request its full screen
> playback surface be preferentially placed on a TV-type output, while
> configuration tools would request being shown on a laptop-screen-type
> output.
>
> For screensaver inhibition, it was suggested that this be tracked
> per-surface, so that when the surface terminates the inhibition is
> removed (this is essentially what xdg-screensaver tries to do, although
> is specific to the client process rather than window iirc).

It's similar to
http://standards.freedesktop.org/idle-inhibit-spec/latest/re01.html

It would require careful semantics that I'm not so sure about. Why is
it being tied to the surface rather than the process important?

> They also
> suggested per-output blanking support so e.g. laptop lvds could be
> blanked but the projector be inhibited, or when watching a movie on
> dual-head, hyst the non-movie head powersaves off.  They also suggested
> having a 'dim' functionality which would put the display to maximum
> dimness rather than blanking it completely; I'm not sure on the use case
> here or how easy it'd be to implement.

This is stuff I would hope would be provided and implemented by the
DE. As a multimonitor user who quite often watches things on one
monitor while coding on another, I'd turn this feature off.

> I had hoped to discuss collaboration on testing, but without specifics
> there didn't seem to be strong interest.  One question was about
> collecting protocol dumps for doing stability testing or performance
> comparison/optimization with; while we're not doing that currently, that
> sounded straightforward and like it could be useful to investigate more.
>
>
> There was some confusion over what the purpose of xdg-shell really is;
> it was looked at as a reference implementation rather than as a
> lowest-common denominator that should be built *onto*.  So it seems that
> Wayland have some messaging to do to ensure xdg-shell really is
> 'cross-desktop'.

xdg-shell should be seen as the proper shell protocol everybody should
strive to support. It's entirely possible that DEs have their own
protocols they put on top: GTK+ has gtk-shell, for instance.

> Bryce
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel



-- 
  Jasper