On Fri, Dec 2, 2016 at 8:19 PM, Cedric BAIL <cedric.b...@free.fr> wrote:
> Hi,
>
> On Fri, Dec 2, 2016 at 8:54 AM, Bruno Dilly <bdi...@profusion.mobi> 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.
>
It's easy to be done, a very few lines are required.
But if you're customizing seat names, you could name them as
"seat1", "seat2"... and they would match EDC names.
On the other hand, if we emit for both sequential names and
evas names, if you name them as seat1, seat2... in the end
you receive duplicated events...
And when you receive them on C code, you would need to
figure out if they're custom names and use edje API to get the seat device,
or if they're evas names, and use evas API to get the seat device...
Having both at the same times seems to make things a bit harder.
Adding an API to select what approach to be used seems acceptable?
By default using seat1, seat2, but you could require evas_names?
Something like
edje_multiseat_evas_names_set(bool) ?
So you could write your EDC / code knowing if names would be
following Edje or Evas.
>
> 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.
>
It was kind of out of the proposal, indeed.
I'll take a look on it soon and ping you back about it.
>
> 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 ?
>
I'm not sure if I get what do you mean, here.
Have you had the opportunity to test the example I've written?
I've added a couple drag bars on it, that change colors in different ways
depending on which seat is handling them. So seats can move
different drags at the same time, or could even try to use the same
at the same time, and code would receive signals saying which seat
changed it.
>
> 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 ?
>
Once again, it can be done, we could add an API to disable a seat,
so on _edje_seat_emit() it would look if the seat was disabled
before emitting the signal. But would you stop emitting signals
for this seat but allow it to interact with your interface? Or
are you looking for a way to disable it on Evas, and consequently
no edje signal would be emiitted?
It doesn't seem to be very edjish for me, since we don't have API
to disable listening for specific signals, right? Can I disable
mouse,up for a specific button, or disable drags, etc?
I believe that usage would be something about two use cases:
1) You want to listen for any seat:
signal: "mouse,in,*"
2) You want to listen for a specific seat:
signal: "mouse,in,seat3"
If something else more complex is required, like filtering out a
specific seat, or only applying it to even seat numbers, must
probably the only way to do it is using C code, listening for
"mouse,in,*" and defining what to do depending on seat.
> --
> Cedric BAIL
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
Bruno Dilly
ProFUSION embedded systems
http://profusion.mobi
------------------------------------------------------------------------------
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
