(Still talking about the Evas/Object_OBject block API)
By default everyone is allowed to play with the widget and we can create a
seat "blacklist", which we will ignore any event that come from it. Coding
this way, we will also fulfill the Cedric's drag concerns. Which I can
specify which seat(s) are allowed to drag the object(s)
On Mon, Dec 5, 2016 at 5:43 PM, Guilherme Íscaro <isc...@profusion.mobi>
wrote:
> 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
