If we are going to block events from seats I prefer to create an API
directly on Evas/Evas_Object. By doing so others can also take advantage of
this API. I would also like to add that we should block keyboard events and
focus/unfocus events - to keep things sane.
On Mon, Dec 5, 2016 at 5:34 PM, Bruno Dilly <bdi...@profusion.mobi> wrote:
> 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
>
------------------------------------------------------------------------------
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
