Re: [E-devel] Edje multiseat support

[Cedric B. <ced...@fr...>]

Hi,

On Fri, Dec 2, 2016 at 8:54 AM, Bruno Dilly <bd...@pr...> wrote:
> now that multiseat is supported up to Evas, we’re working on Edje.

Yeah \o/

> The idea is that a developer would be able to implement an UI that
> may be used by more than one single seat, properly handling focus,
> and providing different feedback for different seats action.
>
> Let’s say, different colors on focus, different images when different
> seat pointers are over, etc.
>
> I’ve done an initial implementation and wrote an example. It’s available
> on my branch devs/bdilly/edje_multiseat . There you’ll be able to find
> edje_multiseat example (C code + EDC).
>
> To make this possible, a few main changes were done:
>   *  New signals were added, adding the seat as suffix. So “mouse,in” would
> be still be emitted, but also “mouse,in,seat1”, for example
>   * Real Parts now may be focused by multiple seats
>   * Some actions receive an optional seat parameter. For instance,
> FOCUS_SET may receive the seat name, or it will consider it's about the
> default seat.
>    * Since Evas seat devices may have arbitrary names (at least using
> wayland backend you can name them as you want using udev rules), or set
> them on programmatic ways, Edje will have custom names for seats, following
> a well established pattern. So first announced seat will be named “seat1”,
> the second “seat2”... If an application supports three seats, on EDC you
> know what signals you should expect. It makes it possible to write general
> applications (in the sense of not knowing exactly seats beforehand). But
> let’s say it’s not the case. there is a specific product built in a way
> that they know exactly which seats are supported and configured their
> names, or want to check if this seat has pointer, keyboard, or whatever…
> for this cases, Edje also emits signals saying when devices were added (or
> removed) and their names. With these names you can use a new Edje function
> to fetch the Evas device named as “seat1”.

I think it would be better to actually emit both a "event,seat1" and a
"event,seat_named". It will be easier to use from theme where named
seat have been customized and won't cost much more I think.

Something that seems out of the proposal is text cursor. I think we
want to be able to assign a seat per Edje_Cursor so that we have
multiple people able to mess with an entry, but I know that Tom and
Daniel have been working on redefining the API there. So I am not sure
about what needs to be done in that context. Maybe they can share
there thinking on the topic.

Another case, that I think we want to handle somehow is specific drag
per seat. If you look at edje_callback.c, you will see that we need to
handle seat in that context too. I would guess we want to set some
kind of filter via both API and theme. Do you have an opinion on that
bit already ?

Also if we are to do a theme in elementary that support multi seat, I
would expect to be able to disable a widget for a specific seat in the
C code. Wouldn't it make sense ? So in which case, wouldn't an API to
disable listening for an entire seat make sense also on edje ? Or do
you have an idea on how to implement that doesn't require this ?
-- 
Cedric BAIL