EFL/Wayland and xdg-shell

[Carsten Haitzler (The Rasterman)]

On Mon, 13 Apr 2015 17:24:26 -0700 "Jasper St. Pierre" <jstpierre at mecheye.net>
said:

> On Mon, Apr 13, 2015 at 5:02 PM, Bryce Harrington <bryce at osg.samsung.com>
> 
> > 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?

ok. hmmm. this is an actual business use case (requirement) not theory. i have
been asked for this. let us pretend now we have a "desktop ui" where some
windows are rotated, but some are not. when a window rotates 90 degrees is must
ALSO resize to a new size at the same time. imagine 800x480 -> 480x800 WHILE
rotating. but the widgets within the window have to re-layout AS the rotation
animation happens. let us also have the compositor doing the rotation (so it's
rotating the output buffer from the app whilst it resizes from size A to size
B). the client would need to be told the current rotation at any point during
this animation so it can render its layout differences accordingly as well.
either that or the rotate animation is totally client driven and it is
informing the compositor of the current rotation needed. imagine 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.

i would disagree. input methods should be a core part of the protocol as they
are input. vkbd's, or cjk or anything else is a complex case of input, but
still input. input should come from the compsitor.

in x11 we use properties to advertise to clients which area(s) of the screen
have been obscured by the vkbd, so clients can scroll/move/re-layout content to
ensure the entry you are typing into isnt hidden under your on-screen keyboard.
this is needed in wayland eventually.

> > 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?

because inhibition is about an app saying "my window content is important -
keep it visible and don't blank/dim etc.". people brute-force use a global
control because that is all they have had, but it is really about content. that
surface is playing a movie - when doing so - tag that surface as "please don't
blank me!" (and likely another flag like "please don't dim me!"). if the
surface is destroyed, hidden, moved to another virtual desktop - the inhibition
can be lifted by the compositor as the content's desire to be always visible is
now irrelevant due to context. and no-fullscreen mode does not equate to
"inhibit screensaver".

> > 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.

thus why it should be on a surface. if my movie playback is on my external "tv"
monitor and it asks to inhibit - the compositor will stop blanking the external
screen, but it may happily blank the internal screen on the laptop - which is
exactly what we really would want. if the information is per-surface, this kind
of smart behavior is possible. there is no need for apps to know about multiple
monitors and which to inhibit if the inhibition is tied to a surface.

> > 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.

we also will likely extend too with some e-shell as it means we can prototype
and implement new features rapidly, and then consider bringing them up for
standardization in xdg-shell.

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com