EFL/Wayland and xdg-shell

[Giulio Camuffo]

2015-04-14 6:33 GMT+03:00 Derek Foreman <derekf at osg.samsung.com>:
> On 13/04/15 07:31 PM, Daniel Stone wrote:
>> Hi,
>>
>> On 14 April 2015 at 01:02, Bryce Harrington <bryce at osg.samsung.com> wrote:
>>> 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?
>>
>> The window doesn't know it's rotated. The rotation occurs as part of
>> the translation into global co-ordinate space (perhaps more than one,
>> perhaps multiple instances, etc), which the client is unaware of. If
>> it wasn't unaware of it, things like input would also be broken.
>
> It's intended to allow for the usual level of EFL/Enlightenment eye candy.
>
> I don't think having a window perpetually at a 35 degree angle is the
> intended use case - having the app know that the screen has been rotated
> so it can participate in a glorious animation sequence while its window
> is transitioning from 0 to 90 degree rotation is.

When the output is rotated you get a geometry event with the transform
so you can animate all you want, so that use case is already covered.


>
>>> 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.
>>
>> So not just animating the transition, but requesting the client
>> animate the content as well? That's extremely esoteric, and seems like
>> it belongs in a separate extension - which is possible.
>
> Nod, that may be the way we go.  Raster's already expressed an interest
> in having our own efl-shell protocol for all our needs.  Bryce and I are
> trying to sift through internal requirements and figure out what, if
> anything, can be shared.
>
>>>   * Arbitrary shaped (non-rectangular) windows.  Dynamically shaped
>>>     windows.
>>
>> Entirely possible: input/opaque regions can be of arbitrary shape.
>>
>>>   * Non-linear surface movement/resizing animations and transition
>>>     effects.
>>
>> This seems like a compositor thing?
>>
>>> 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.
>>
>> It's sadly not been unmaintained for a while.
>
> I've been poking at it a bit lately and have a stack of bug fixes.  I
> also think the compositor should be involved in the hide/show decision
> instead of leaving it entirely up to the client (give the client
> hide/show/auto settings...).  I've got some work done in that direction
> but it's not ready for the light of day yet.
>
> I suspect this could end up in a thread of its own though.  Assuming
> text protocols are still something we want in core wayland - Jasper
> seemed to indicate gnome's going its own way in this regard...
>
>>> 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.
>>
>> See the text_cursor_position protocol.
>
> More than that there was talk of wanting a way for a client such as a
> vkbd to get occlusion regions for the whole screen to help it lay things
> out.
>
> And for clients in general to be able to request their own occluded
> regions so they could attempt to layout things around occluded areas.
>
>>> Security is also a top concern here, to ensure
>>> unauthorized clients can't steal keyboard input if (when) the virtual
>>> keyboard client crashes.
>>
>> The compositor is responsible for starting the input method client
>> (VKB) and directing input. Weston is already very good at isolating
>> these clients from the rest; any other compositor should follow
>> Weston's model here.
>
> I'm not sure this is a solved problem.  If I read the code correctly,
> only one VKB can exist, and it would have to provide both overlay and
> keyboard functionality.  It may be that we want different installable
> keyboards and overlays that can be configured at run time.
>
> I think the details of authenticating the correct keyboard should
> probably be left out of the protocol, but limiting to a single input
> provider that must do both overlay and keyboard may be worth changing at
> the protocol level?
>
> Similarly, it may be that each seat wants a different VKB provider?
>
>>> 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...
>>
>> RandR is a disaster of an API to expose to clients. I would suggest
>> that anything more than a list of monitors (not outputs/connectors)
>> with their resolutions, relative monitor positioning, and the ability
>> to change/disable the above, is asking for trouble.
>
> I do like the idea of hiding the concept of outputs and connectors very
> much.  :)
>
> This still gets ugly in a hurry.  Someone's obviously going to want to
> add a mode that doesn't show up in their EDID block...
>
>>> 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.
>>
>> A neat idea, but a separate extension to be sure. Flipping things
>> around a bit, you might say that the application declares its type,
>> and the compositor applies smart placement depending on its type.
>
> That's much the way the internal discussion went. :)
>
>>> 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).
>>
>> Very much so.
>>
>>> 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.
>>
>> If you have a per-surface inhibition API, per-output blanking becomes
>> an implementation detail.
>
> Right.  And Jasper and I can continue to turn it off.  :)
>
> I think the non-standard bit from this paragraph is wanting to have
> dimability (totally a real word) and blanking be separately controlled
> by a client.
>
>>> 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.
>>
>> I'd like to see FITS revived, or the better bits of it moved into
>> Weston's test suite. Protocol dumps aren't particularly useful as
>> they're very dependent on things like exact file descriptors;
>> replaying a protocol dump is basically exactly what a test client
>> does. We can measure how quickly those run.
>
> Bryce is coming from the cairo world where cairo-trace dumps are a great
> way to see where an app is sucking.  I don't know if WESGR fills (or
> intends to fill) this role.
>
> I think the important thing here is taking a full up application that's
> perhaps not performing as intended and having a way to diagnose that.
> Whether that's part of weston or some external protocol analyzer tool
> seems fairly unimportant though...
>
> That said, yeah... reviving FITS and or moving the better parts of it
> into weston's test suite seems like a great idea to me. :)
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel