EFL/Wayland and xdg-shell

[Jasper St. Pierre]

On Mon, Apr 13, 2015 at 7:59 PM, Derek Foreman <derekf at osg.samsung.com> wrote:

... snip ...

> That all makes sense - set_window_geometry() was a bit of a red herring
> here.
>
> Some EFL developers want the application to have a way to know its
> rotation so it can, for example, render drop shadows correctly.
>
> Take a window in weston and rotate it 90 or 180 degrees and the drop
> shadow is "wrong".

Boo hoo. While you're at it, why don't you also write a proper
implementation of shadows that takes the alpha channel into account,
so every single letter on your transparent terminal casts a shadow on
the underlying content, leaving it an unreadable mess?

> Drop shadows are just the easy example, there's also a desire to have
> the applications react to the rotation in some way so the usual EFL
> bling can take place during a a smooth rotation from 0-90 degrees, for
> example.

Use a custom protocol for this. I don't think any other client has
ever cared. UI elements are caricatures for clarity, drop shadows are
used to establish focus and layering, and you're the only ones who
want physically-based rendering raytraced desktops.

> I do wonder if drop shadows really should be the client's responsibility
> at all.  If completely non-interactive eye-candy was left to the
> compositor, would we still need set_window_geometry() at all?

Yes. First of all, invisible borders are still a use case, unless you
think those should be provided by the compositor as well (which means
that the compositor must be more complex and handle fancy events
itself). And when using subsurfaces, you need an understanding of
whether it's the union of the surfaces or one specific surface that's
the main window.

>>> 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?
>
> It's not directly impeded I suppose - it's just not currently possible?
>  The client doesn't know it's being rotated (at least when talking about
> arbitrary rotations, as opposed to the right angle transforms)

Good. Window rotation is a gimmick feature designed to show off that
Wayland can transform input directly without having to send a
transformation mesh to the X server.

>> 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.
>
> That may be in line with the current thinking in the EFL camp.
>
> Does that mean the input-method and text protocol files in weston are of
> no use at all to gnome?

These are currently unused by GNOME. They were written by Openismus,
the company that wrote Maliit, that has shut down now. In my opinion,
it's too complicated, mandates a split where the keyboard needs to be
replaceable.

I'm not sure the text-protocol has any value at all, but I'll let Rui
Matos, our input method "expert", answer.

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

> It's an idea that's being thrown around.  "We" would like to have the
> ability to put outputs to sleep independently... If the surface is
> dragged from one output to another the blanker inhibition would move
> with it without the client having to do anything.

Ah, that's an interesting idea. I'd be fine with that, but I'd much
prefer experimentation in a private protocol first. There's plenty of
usage issues I can imagine running into (e.g. I press Alt-Tab, and
since the surface appears on the other output for a split-second, it
wakes back up.  Or my mouse is suddenly invisible, etc. Or I have my
presentation running and the presentation window is on the monitor
with inhibit, and my notes suddenly fall asleep).

> Is gtk-shell intended to be a test bed for things that will eventually
> be in xdg-shell?  Or are divergent standards a guarantee at this point?

Either that, or, more hopefully, for stuff that is so GTK+ specific
that there's no value in standardization. The equivalent of a _GTK_*
property on an X11 window.

-- 
  Jasper