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 ? > 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. > 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
