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