On Mon, Dec 5, 2016 at 5:10 PM, Cedric BAIL <cedric.b...@free.fr> wrote:
> On Mon, Dec 5, 2016 at 6:26 AM, Bruno Dilly <bdi...@profusion.mobi> wrote:
> > On Fri, Dec 2, 2016 at 8:19 PM, Cedric BAIL <cedric.b...@free.fr> wrote:
> >> On Fri, Dec 2, 2016 at 8:54 AM, Bruno Dilly <bdi...@profusion.mobi>
> wrote:
> >> > 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?
>
> I don't think an API would work as you only know in the theme if it
> handles them. Maybe better would be a flag in the edje group. Do you
> think that would be ok ?
>
>
Yeah, it seems to be a good idea.
I'll try it soon. Thanks
> > 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.
>
> Ah, yes, I forgot 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?
>
> Yes, they help understand the current scope.
>
> > 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.
>
> So what if I want to allow a drag just for one seat ? Or a set of seat
> ? Is that possible ? When I looked at edje_callback.c I couldn't see
> any way to prevent the signal from beeing emitted for a specific seat.
>
> >> 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?
>
> More the later. The idea is imagine you have an application with
> multiple user. Each user are allowed to modify their name and color
> code, but other users shouldn't be able to touch those widget. Or if
> you have a dialog where just one user is allowed to answer, you don't
> want anyone else to tincker with it. So there shouldn't be any mouse
> over effect triggered on the edje object. As an edje object is seen as
> kind of a sandbox, you could think that if you give ownership of a
> widget to a seat, no other seat should have any effect at all on it.
>
> > 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 hope my description above give you an idea where I am going with this.
>
>
Right, right!
I believe I understood what you want, now.
I need to study about it a bit, but I have some initial ideas.
If we need a fine-grained control, like this kind of control over parts,
not only the whole edje object, maybe something like a property
for parts, like "mouse_events", but per seats could do the trick.
A list of seats allowed to emit mouse_events, maybe?
Something like:
mouse_events_seats: [seat1] [seat2] ...
part {
name: "rect";
type: RECT;
mouse_events: 1;
mouse_events_seats: "seat1" "seat3";
description {
state: "default" 0.0;
}
}
I'll give it a try later, let's see if it works
But if we're talking about some seats not allowed to mess with
edje objects, maybe we could target on enabling / disabling
events per seats on Evas (and actually mouse_events_seats would
be a user for this new Evas API).
What do you think about, Iscaro?
> > 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.
>
> That wouldn't work as you would not be able to prevent animation
> triggered by any of this events. Also I would expect elementary to
> have some kind of ownership API once we start rolling multi seat in
> it. Something where you can say, this widget only belong to this set
> of seat. Not sure at all of the API, but definitively the way to go if
> we handle multi seat in the widgets sets.
> --
> Cedric BAIL
>
> ------------------------------------------------------------
> ------------------
> _______________________________________________
> 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
