EFL/Wayland and xdg-shell

[Derek Foreman]

On 13/04/15 10:19 PM, Jasper St. Pierre wrote:
> 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?

An interesing idea, but nobody here is interested in it.  I'm willing to
review the patches if you write them though - just remember to CC me.

We do have interest in doing things like gaussian blurs, which present
an interesting problem (but I don't believe an unsolvable one) in a CSD
world.

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

Fair enough.

I do hope nobody thinks we're expecting other people to do our homework
for us - we want to find a subset of our needs that can be met with
changes to the core protocol to minimize the size of "efl-shell" or
whatever it becomes.

We're hoping this mail thread can help us decide what we should be
working towards adding to weston/wayland and what we should be doing
exclusively in efl.

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

We don't really have a use case for invisible borders.  Does KDE?  Is
this a gnome only feature?

I must confess to not immediately grokking the ramifications of having a
specific surface be "the main window" of an application.

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

What good is proving that can be done if you can't do anything useful
with it?

I see our needs being met in one of two ways:
Allow the compositor to tell the client its rotation angle
Allow the client to tell the compositor the rotation angle it wants

The first lets the compositor drive the animation, but if the client
can't get a frame out in time things won't look quite right.

The second lets the clients drive their own rotation animation, but if
the cpu can't keep up the windows of multiple clients won't be oriented
exactly the same way.

Either way, at the end of the animation the rotation would be disabled
and transforms would be used.

You'd be dead set against either of these?

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

Replaceable keyboards are a requirement for us as well.

The current input-method stuff also doesn't handle multi-seat at all
well.  We're still on the fence as to whether this is something we
should be trying to fix in weston/wayland or something that we'll NIH.

At least it seems that our efforts here won't directly conflict with
your goals.

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

Notes falling asleep would appear to be a client bug.  :)

The others will be good things to watch out for as we move forward with
this.

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

Cool.

It's starting to look like the efl equivalent may end up being fairly
large. :/