Re: [E-devel] Edje multiseat support

[The Rasterman]

On Mon, 5 Dec 2016 11:37:09 -0200 Guilherme Íscaro  said:

> Hi raster,
> 
> i'm seeing over 1mb of hash entries being used by
> >
> > _evas_object_pointer_data_get()
> >
> > (called from _efl_canvas_object_pointer_mode_by_device_set()).
> >
> >
> I will take a look and check if we can improve the memory usage here, if
> you want we can discuss solutions about this one. Btw, thank you for your

this definitely should be a few kb at most not 1mb+. :) i haven't sat down and
tried to figure out what this code is trying to do and why... but we shouldn't
need mountains of extra memory just for the ability to handle multiple seats :)

> commit fixing the mouse problem!

no problems. :)

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Edje multiseat support

[Jean-Philippe André]

Hi,

On 6 December 2016 at 09:53, Bruno Dilly  wrote:

> On Mon, Dec 5, 2016 at 8:47 PM, Simon Lees  wrote:
>
> >
> >
> > On 12/06/2016 01:18 AM, Bruno Dilly wrote:
> > > Hi jpeg,
> > >
> > > On Mon, Dec 5, 2016 at 2:21 AM, Jean-Philippe André  >
> > > wrote:
> > >
> > >> Hi,
> > >>
> > >>
> > >> This seems to assume a finite and known in advance number of seats?
> > >> I'm not well aware of what the seats are or how that's all supposed to
> > >> work, but this sounds strange to me.
> > >>
> > >>
> > > On theme point of view, I can't see how this could be any different.
> > > If you don't know how many seats do you support or which seats would be
> > > supported,
> > > how could you be able to design it?
> > >
> > > EDC is pretty much a lot of parts with different states and programas
> > > listening to specific signals-sources and taking an action when it
> > matches.
> > > Everything is hardcoded on EDC files, right?
> > >
> > > But nothing stops you to create an UI more dynamic on code.
> > > You could listen to "seat,added,X" and create a random color
> > > to represent it. Then when you receive "mouse,over,X" for specific
> parts,
> > > you could change their colors, images, emit different sounds or
> whatever
> > > that makes sense for you.
> > >
> > >
> > >
> > >> Maybe someone can enlighten me? Why would the theme know the number of
> > >> seats?
> > >> (the approach probably makes perfect sense but i'm not sure what edje
> > >> should do wrt. seats)
> > >>
> > >
> >
> > I can't remember if you can currently do something like the % operator
> > with edje, but you could make it so that the first 4 seats get different
> > colors and then the 5th gets the same as the first. If you were only
> > trying to do colors if you can extract the X part (again don't remember
> > if this is possible) you could use a macro and substitute in a lookup
> > table for colors (saves writing every part X times)
> >
>
> Using scripts it is doable.
> Lets say, you could do something like:
>
>  program {
> name: "part,in";
> signal: "mouse,in,*";
> source: "part";
> script {
> handle_mouse_in(sig);
> }
>  }
>
> on handle_mouse_in you would be able to get the seat name
> using something like strcpy(seat_name, sig[strlen("mouse,in,")]);
>
> You could even create a list and append new random colors for each
> announced seat.
>
> But it's not only about colors, you could select images, or font size /
> families... anything
> that could matter for a theme.
>

Thanks for the response, Bruno.
This is all pretty much what I had in mind, I just wanted clarification.

And indeed beyond scripting or app code I can't see how we would design for
N users.

-- 
Jean-Philippe André
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Edje multiseat support

[Bruno Dilly]

On Mon, Dec 5, 2016 at 10:53 PM, Bruno Dilly  wrote:

>
>
> On Mon, Dec 5, 2016 at 8:47 PM, Simon Lees  wrote:
>
>>
>>
>> On 12/06/2016 01:18 AM, Bruno Dilly wrote:
>> > Hi jpeg,
>> >
>> > On Mon, Dec 5, 2016 at 2:21 AM, Jean-Philippe André 
>> > wrote:
>> >
>> >> Hi,
>> >>
>> >>
>> >> This seems to assume a finite and known in advance number of seats?
>> >> I'm not well aware of what the seats are or how that's all supposed to
>> >> work, but this sounds strange to me.
>> >>
>> >>
>> > On theme point of view, I can't see how this could be any different.
>> > If you don't know how many seats do you support or which seats would be
>> > supported,
>> > how could you be able to design it?
>> >
>> > EDC is pretty much a lot of parts with different states and programas
>> > listening to specific signals-sources and taking an action when it
>> matches.
>> > Everything is hardcoded on EDC files, right?
>> >
>> > But nothing stops you to create an UI more dynamic on code.
>> > You could listen to "seat,added,X" and create a random color
>> > to represent it. Then when you receive "mouse,over,X" for specific
>> parts,
>> > you could change their colors, images, emit different sounds or whatever
>> > that makes sense for you.
>> >
>> >
>> >
>> >> Maybe someone can enlighten me? Why would the theme know the number of
>> >> seats?
>> >> (the approach probably makes perfect sense but i'm not sure what edje
>> >> should do wrt. seats)
>> >>
>> >
>>
>> I can't remember if you can currently do something like the % operator
>> with edje, but you could make it so that the first 4 seats get different
>> colors and then the 5th gets the same as the first. If you were only
>> trying to do colors if you can extract the X part (again don't remember
>> if this is possible) you could use a macro and substitute in a lookup
>> table for colors (saves writing every part X times)
>>
>
> Using scripts it is doable.
> Lets say, you could do something like:
>
>  program {
> name: "part,in";
> signal: "mouse,in,*";
> source: "part";
> script {
> handle_mouse_in(sig);
> }
>  }
>
> on handle_mouse_in you would be able to get the seat name
> using something like strcpy(seat_name, sig[strlen("mouse,in,")]);
>
> You could even create a list and append new random colors for each
> announced seat.
>
> But it's not only about colors, you could select images, or font size /
> families... anything
> that could matter for a theme.
>

I've pushed a commit to my branch (devs/bdilly/edje_multiseat) adding an
example
of how to make a theme with no assumptions regarding the amount of seats to
be
supported. It's edje-dynamic-multiseat.

Despite simple - it just change color classes depending on which seat is
over a part - it let's
clear that multiseat works on this scenario.

Sure, we need to use scripts for that, since we don't want to hardcode all
possible seats on theme:
EDC file looks like this:
http://pastebin.com/9YCRRZAN

Regards


>
>
>
>>
>> --
>>
>> Simon Lees (Simotek)http://simotek.net
>>
>> Emergency Update Team   keybase.io/simotek
>> SUSE LinuxAdeliade Australia, UTC+9:30
>> GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
>>
>>
>> 
>> --
>> Developer Access Program for Intel Xeon Phi Processors
>> Access to Intel Xeon Phi processor-based developer platforms.
>> With one year of Intel Parallel Studio XE.
>> Training and support from Colfax.
>> Order your platform today.http://sdm.link/xeonphi
>> ___
>> 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
>



-- 
Bruno Dilly
ProFUSION embedded systems
http://profusion.mobi
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Edje multiseat support

[Bruno Dilly]

On Mon, Dec 5, 2016 at 8:47 PM, Simon Lees  wrote:

>
>
> On 12/06/2016 01:18 AM, Bruno Dilly wrote:
> > Hi jpeg,
> >
> > On Mon, Dec 5, 2016 at 2:21 AM, Jean-Philippe André 
> > wrote:
> >
> >> Hi,
> >>
> >>
> >> This seems to assume a finite and known in advance number of seats?
> >> I'm not well aware of what the seats are or how that's all supposed to
> >> work, but this sounds strange to me.
> >>
> >>
> > On theme point of view, I can't see how this could be any different.
> > If you don't know how many seats do you support or which seats would be
> > supported,
> > how could you be able to design it?
> >
> > EDC is pretty much a lot of parts with different states and programas
> > listening to specific signals-sources and taking an action when it
> matches.
> > Everything is hardcoded on EDC files, right?
> >
> > But nothing stops you to create an UI more dynamic on code.
> > You could listen to "seat,added,X" and create a random color
> > to represent it. Then when you receive "mouse,over,X" for specific parts,
> > you could change their colors, images, emit different sounds or whatever
> > that makes sense for you.
> >
> >
> >
> >> Maybe someone can enlighten me? Why would the theme know the number of
> >> seats?
> >> (the approach probably makes perfect sense but i'm not sure what edje
> >> should do wrt. seats)
> >>
> >
>
> I can't remember if you can currently do something like the % operator
> with edje, but you could make it so that the first 4 seats get different
> colors and then the 5th gets the same as the first. If you were only
> trying to do colors if you can extract the X part (again don't remember
> if this is possible) you could use a macro and substitute in a lookup
> table for colors (saves writing every part X times)
>

Using scripts it is doable.
Lets say, you could do something like:

 program {
name: "part,in";
signal: "mouse,in,*";
source: "part";
script {
handle_mouse_in(sig);
}
 }

on handle_mouse_in you would be able to get the seat name
using something like strcpy(seat_name, sig[strlen("mouse,in,")]);

You could even create a list and append new random colors for each
announced seat.

But it's not only about colors, you could select images, or font size /
families... anything
that could matter for a theme.



>
> --
>
> Simon Lees (Simotek)http://simotek.net
>
> Emergency Update Team   keybase.io/simotek
> SUSE LinuxAdeliade Australia, UTC+9:30
> GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
>
>
> 
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today.http://sdm.link/xeonphi
> ___
> 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
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Edje multiseat support

[Simon Lees]

On 12/06/2016 01:18 AM, Bruno Dilly wrote:
> Hi jpeg,
> 
> On Mon, Dec 5, 2016 at 2:21 AM, Jean-Philippe André 
> wrote:
> 
>> Hi,
>>
>>
>> This seems to assume a finite and known in advance number of seats?
>> I'm not well aware of what the seats are or how that's all supposed to
>> work, but this sounds strange to me.
>>
>>
> On theme point of view, I can't see how this could be any different.
> If you don't know how many seats do you support or which seats would be
> supported,
> how could you be able to design it?
> 
> EDC is pretty much a lot of parts with different states and programas
> listening to specific signals-sources and taking an action when it matches.
> Everything is hardcoded on EDC files, right?
> 
> But nothing stops you to create an UI more dynamic on code.
> You could listen to "seat,added,X" and create a random color
> to represent it. Then when you receive "mouse,over,X" for specific parts,
> you could change their colors, images, emit different sounds or whatever
> that makes sense for you.
> 
> 
> 
>> Maybe someone can enlighten me? Why would the theme know the number of
>> seats?
>> (the approach probably makes perfect sense but i'm not sure what edje
>> should do wrt. seats)
>>
> 

I can't remember if you can currently do something like the % operator
with edje, but you could make it so that the first 4 seats get different
colors and then the 5th gets the same as the first. If you were only
trying to do colors if you can extract the X part (again don't remember
if this is possible) you could use a macro and substitute in a lookup
table for colors (saves writing every part X times)

-- 

Simon Lees (Simotek)http://simotek.net

Emergency Update Team   keybase.io/simotek
SUSE LinuxAdeliade Australia, UTC+9:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B



signature.asc
Description: OpenPGP digital signature
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Edje multiseat support

[Guilherme Íscaro]

(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 
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  wrote:
>
>> On Mon, Dec 5, 2016 at 5:10 PM, Cedric BAIL  wrote:
>>
>> > On Mon, Dec 5, 2016 at 6:26 AM, Bruno Dilly 
>> wrote:
>> > > On Fri, Dec 2, 2016 at 8:19 PM, Cedric BAIL 
>> wrote:
>> > >> On Fri, Dec 2, 2016 at 8:54 AM, Bruno Dilly 
>> > 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
>> sur

Re: [E-devel] Edje multiseat support

[Guilherme Íscaro]

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  wrote:

> On Mon, Dec 5, 2016 at 5:10 PM, Cedric BAIL  wrote:
>
> > On Mon, Dec 5, 2016 at 6:26 AM, Bruno Dilly 
> wrote:
> > > On Fri, Dec 2, 2016 at 8:19 PM, Cedric BAIL 
> wrote:
> > >> On Fri, Dec 2, 2016 at 8:54 AM, Bruno Dilly 
> > 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 fil

Re: [E-devel] Edje multiseat support

[Bruno Dilly]

On Mon, Dec 5, 2016 at 5:10 PM, Cedric BAIL  wrote:

> On Mon, Dec 5, 2016 at 6:26 AM, Bruno Dilly  wrote:
> > On Fri, Dec 2, 2016 at 8:19 PM, Cedric BAIL  wrote:
> >> On Fri, Dec 2, 2016 at 8:54 AM, Bruno Dilly 
> 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
> > c

Re: [E-devel] Edje multiseat support

[Cedric BAIL]

On Mon, Dec 5, 2016 at 6:26 AM, Bruno Dilly  wrote:
> On Fri, Dec 2, 2016 at 8:19 PM, Cedric BAIL  wrote:
>> On Fri, Dec 2, 2016 at 8:54 AM, Bruno Dilly  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 d

Re: [E-devel] Edje multiseat support

[Bruno Dilly]

Hi jpeg,

On Mon, Dec 5, 2016 at 2:21 AM, Jean-Philippe André 
wrote:

> Hi,
>
>
> This seems to assume a finite and known in advance number of seats?
> I'm not well aware of what the seats are or how that's all supposed to
> work, but this sounds strange to me.
>
>
On theme point of view, I can't see how this could be any different.
If you don't know how many seats do you support or which seats would be
supported,
how could you be able to design it?

EDC is pretty much a lot of parts with different states and programas
listening to specific signals-sources and taking an action when it matches.
Everything is hardcoded on EDC files, right?

But nothing stops you to create an UI more dynamic on code.
You could listen to "seat,added,X" and create a random color
to represent it. Then when you receive "mouse,over,X" for specific parts,
you could change their colors, images, emit different sounds or whatever
that makes sense for you.



> Maybe someone can enlighten me? Why would the theme know the number of
> seats?
> (the approach probably makes perfect sense but i'm not sure what edje
> should do wrt. seats)
>

I can see two different use cases here:

1) you're developing an specific product and you know the limit of seats
that is supported.

When you're writing a game for a console you know that you support 2, or 4
different players,
and know how to interact with each controller, right?

In this case you just have multiple states for EDC parts to represent which
seat is interacting
with it and programs for that.

2) you're developing a program that could handle as many seats as the user
want to add

You'll need to modify your UI in a programmatic way, changing Edje parts
with the API or
sending custom signals or messages for your theme.

I'll create an example exercising this idea. Indeed edje_multiseat example
just cover
the first scenario. Maybe some challenges (and consequently, improvements
on Edje)
may come from this.

Thanks


>
>
> TIA,
>
>
> On 4 December 2016 at 10:58, Carsten Haitzler 
> wrote:
>
> > On Sat, 03 Dec 2016 15:24:17 + Gustavo Sverzut Barbieri
> >  said:
> >
> > > Just seat1, seat2...
> > >
> > > That's what I said we found unusable to get "bob", "jane" in EDC.
> > >
> > > In C you could snprintf() and add signals, or register with ",*" and
> then
> > > parse, BUT that's only in C or bindings, not EDC/Embryo since in a
> > > script/program you can't know the signal that triggered you.
> > >
> > > In C you can retrieve bob from seat1, seat1 from bob and map
> accordingly.
> >
> > ok. so edje will stick to simple seat1, seat2 etc. ok. sensible.
> >
> > > From edc point of view, you can only write theme based on something you
> > > know. Like assign focus color red to seat1, green to seat2, blue to
> > seat3.
> > > If you get bob, you can't figure it out since it is dependent on the
> > system
> > > configuration.
> >
> > yeah. unless the app emits these signals specifically as part of the edje
> > <->
> > app "interface".
> >
> > > Em sáb, 3 de dez de 2016 às 01:20, Carsten Haitzler <
> > ras...@rasterman.com>
> > > escreveu:
> > >
> > > > On Fri, 2 Dec 2016 14:54:20 -0200 Bruno Dilly  >
> > > > said:
> > > >
> > > > > Hi folks,
> > > > >
> > > > > now that multiseat is supported up to Evas, we’re working on Edje.
> > > > >
> > > > > 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).

Re: [E-devel] Edje multiseat support

[Bruno Dilly]

On Fri, Dec 2, 2016 at 8:19 PM, Cedric BAIL  wrote:

> Hi,
>
> On Fri, Dec 2, 2016 at 8:54 AM, Bruno Dilly  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.
>

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?

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.


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

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.



>
> 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 interfac

Re: [E-devel] Edje multiseat support

[Guilherme Íscaro]

Hey Cedric.


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

Currently we're emitting drag signals with the seat prefix like:
"drag,start,seat1". When you say filter, you want to disable drag for a
specific seat ?
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Edje multiseat support

[Guilherme Íscaro]

Hi raster,

i'm seeing over 1mb of hash entries being used by
>
> _evas_object_pointer_data_get()
>
> (called from _efl_canvas_object_pointer_mode_by_device_set()).
>
>
I will take a look and check if we can improve the memory usage here, if
you want we can discuss solutions about this one. Btw, thank you for your
commit fixing the mouse problem!
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Edje multiseat support

[Jean-Philippe André]

Hi,


This seems to assume a finite and known in advance number of seats?
I'm not well aware of what the seats are or how that's all supposed to
work, but this sounds strange to me.

Maybe someone can enlighten me? Why would the theme know the number of
seats?
(the approach probably makes perfect sense but i'm not sure what edje
should do wrt. seats)


TIA,


On 4 December 2016 at 10:58, Carsten Haitzler  wrote:

> On Sat, 03 Dec 2016 15:24:17 + Gustavo Sverzut Barbieri
>  said:
>
> > Just seat1, seat2...
> >
> > That's what I said we found unusable to get "bob", "jane" in EDC.
> >
> > In C you could snprintf() and add signals, or register with ",*" and then
> > parse, BUT that's only in C or bindings, not EDC/Embryo since in a
> > script/program you can't know the signal that triggered you.
> >
> > In C you can retrieve bob from seat1, seat1 from bob and map accordingly.
>
> ok. so edje will stick to simple seat1, seat2 etc. ok. sensible.
>
> > From edc point of view, you can only write theme based on something you
> > know. Like assign focus color red to seat1, green to seat2, blue to
> seat3.
> > If you get bob, you can't figure it out since it is dependent on the
> system
> > configuration.
>
> yeah. unless the app emits these signals specifically as part of the edje
> <->
> app "interface".
>
> > Em sáb, 3 de dez de 2016 às 01:20, Carsten Haitzler <
> ras...@rasterman.com>
> > escreveu:
> >
> > > On Fri, 2 Dec 2016 14:54:20 -0200 Bruno Dilly 
> > > said:
> > >
> > > > Hi folks,
> > > >
> > > > now that multiseat is supported up to Evas, we’re working on Edje.
> > > >
> > > > 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”.
> > > >
> > > > Please let me know about any suggestions or concerns.
> > > >
> > > > I should make a pull request with this initial patchset soon
> > >
> > > wait... so seats can be named... udev rules. so lets say i have seats:
> > >
> > > bob
> > > jane
> > >
> > > i get signals like:
> > >
> > > mouse,in,bob
> > > mouse,out,jane
> > >
> > > right?
> > >
> > > so i ALSO get
> > >
> > > mouse,in,seat1
> > > mouse,out,seat2
> > >
> > > ? so i can write specific seat name handling signal stuff AND also have
> > > generic? or... ?
> > >
> > > --
> > > - Codito, ergo sum - "I code, therefore I am"
> --
> > > The Rasterman (Carsten Haitzler)ras...@rasterman.com
> > >
> > >
> > >
> > > 
> --
> > > 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
> > >
> > 
> --
> > Check out the vibrant tech community on one of the world

Re: [E-devel] Edje multiseat support

[The Rasterman]

On Sat, 03 Dec 2016 15:24:17 + Gustavo Sverzut Barbieri
 said:

> Just seat1, seat2...
> 
> That's what I said we found unusable to get "bob", "jane" in EDC.
> 
> In C you could snprintf() and add signals, or register with ",*" and then
> parse, BUT that's only in C or bindings, not EDC/Embryo since in a
> script/program you can't know the signal that triggered you.
> 
> In C you can retrieve bob from seat1, seat1 from bob and map accordingly.

ok. so edje will stick to simple seat1, seat2 etc. ok. sensible.

> From edc point of view, you can only write theme based on something you
> know. Like assign focus color red to seat1, green to seat2, blue to seat3.
> If you get bob, you can't figure it out since it is dependent on the system
> configuration.

yeah. unless the app emits these signals specifically as part of the edje <->
app "interface".

> Em sáb, 3 de dez de 2016 às 01:20, Carsten Haitzler 
> escreveu:
> 
> > On Fri, 2 Dec 2016 14:54:20 -0200 Bruno Dilly 
> > said:
> >
> > > Hi folks,
> > >
> > > now that multiseat is supported up to Evas, we’re working on Edje.
> > >
> > > 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”.
> > >
> > > Please let me know about any suggestions or concerns.
> > >
> > > I should make a pull request with this initial patchset soon
> >
> > wait... so seats can be named... udev rules. so lets say i have seats:
> >
> > bob
> > jane
> >
> > i get signals like:
> >
> > mouse,in,bob
> > mouse,out,jane
> >
> > right?
> >
> > so i ALSO get
> >
> > mouse,in,seat1
> > mouse,out,seat2
> >
> > ? so i can write specific seat name handling signal stuff AND also have
> > generic? or... ?
> >
> > --
> > - Codito, ergo sum - "I code, therefore I am" --
> > The Rasterman (Carsten Haitzler)ras...@rasterman.com
> >
> >
> >
> > --
> > 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
> >
> --
> 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


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
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 li

Re: [E-devel] Edje multiseat support

[Gustavo Sverzut Barbieri]

Just seat1, seat2...

That's what I said we found unusable to get "bob", "jane" in EDC.

In C you could snprintf() and add signals, or register with ",*" and then
parse, BUT that's only in C or bindings, not EDC/Embryo since in a
script/program you can't know the signal that triggered you.

In C you can retrieve bob from seat1, seat1 from bob and map accordingly.

From edc point of view, you can only write theme based on something you
know. Like assign focus color red to seat1, green to seat2, blue to seat3.
If you get bob, you can't figure it out since it is dependent on the system
configuration.



Em sáb, 3 de dez de 2016 às 01:20, Carsten Haitzler 
escreveu:

> On Fri, 2 Dec 2016 14:54:20 -0200 Bruno Dilly 
> said:
>
> > Hi folks,
> >
> > now that multiseat is supported up to Evas, we’re working on Edje.
> >
> > 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”.
> >
> > Please let me know about any suggestions or concerns.
> >
> > I should make a pull request with this initial patchset soon
>
> wait... so seats can be named... udev rules. so lets say i have seats:
>
> bob
> jane
>
> i get signals like:
>
> mouse,in,bob
> mouse,out,jane
>
> right?
>
> so i ALSO get
>
> mouse,in,seat1
> mouse,out,seat2
>
> ? so i can write specific seat name handling signal stuff AND also have
> generic? or... ?
>
> --
> - Codito, ergo sum - "I code, therefore I am" --
> The Rasterman (Carsten Haitzler)ras...@rasterman.com
>
>
>
> --
> 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
>
--
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

Re: [E-devel] Edje multiseat support

[The Rasterman]

On Sat, 3 Dec 2016 13:26:41 +0900 Carsten Haitzler (The Rasterman)
 said:

> On Fri, 2 Dec 2016 14:54:20 -0200 Bruno Dilly  said:
> 
> lso... this is new:
> 
> i'm seeing e's pointers/cursors getting stuck. it's because mouse out events
> now are missing. tyr mouse over the bottom resize bar on a window, then move
> mouse cursor into the application window above it. cursor still has he resize
> animation thing. it's because mouse,out signal's are missing. this is new in
> the last day or 2. i'm suspecting it may have to do with the new multiseat
> work... i'm digging...

ok. this was added in 484dae76e675318a579e90ac05d4371acc1f8891 october 21. it
seems it's only really become visible recently. 

if (!obj->delete_me) continue;

was wrong in _canvas_event_feed_mouse_out_internal(). no ! there. if the obj is
marked for deletion - skip it... not "is it NOT marked for selection... skip
it" (ie skip if its valid). :)

fixed by 9e8257367df8cf1797ad474b0e8197353651ee5c


> > Hi folks,
> > 
> > now that multiseat is supported up to Evas, we’re working on Edje.
> > 
> > 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”.
> > 
> > Please let me know about any suggestions or concerns.
> > 
> > I should make a pull request with this initial patchset soon
> > 
> > Thank you
> > 
> > -- 
> > Bruno Dilly
> > ProFUSION embedded systems
> > http://profusion.mobi
> > --
> > 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
> 
> 
> -- 
> - Codito, ergo sum - "I code, therefore I am" --
> The Rasterman (Carsten Haitzler)ras...@rasterman.com
> 
> 
> --
> 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


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


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

Re: [E-devel] Edje multiseat support

[The Rasterman]

On Fri, 2 Dec 2016 14:54:20 -0200 Bruno Dilly  said:

lso... this is new:

i'm seeing e's pointers/cursors getting stuck. it's because mouse out events
now are missing. tyr mouse over the bottom resize bar on a window, then move
mouse cursor into the application window above it. cursor still has he resize
animation thing. it's because mouse,out signal's are missing. this is new in
the last day or 2. i'm suspecting it may have to do with the new multiseat
work... i'm digging...

> Hi folks,
> 
> now that multiseat is supported up to Evas, we’re working on Edje.
> 
> 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”.
> 
> Please let me know about any suggestions or concerns.
> 
> I should make a pull request with this initial patchset soon
> 
> Thank you
> 
> -- 
> Bruno Dilly
> ProFUSION embedded systems
> http://profusion.mobi
> --
> 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


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


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

Re: [E-devel] Edje multiseat support

[The Rasterman]

On Fri, 2 Dec 2016 14:54:20 -0200 Bruno Dilly  said:

actually i need to bring up something else...


please memory profile your work!

i'm seeing over 1mb of hash entries being used by

_evas_object_pointer_data_get()

(called from _efl_canvas_object_pointer_mode_by_device_set()).

this is huge! now i have to figure out what even is the point of this code, but
it is new...

how did i see this? just ran enlightenment under valgrind massif and uses
massive visualizer:

http://www.enlightenment.org/ss/e-584241d30671d3.72934687.png

> Hi folks,
> 
> now that multiseat is supported up to Evas, we’re working on Edje.
> 
> 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”.
> 
> Please let me know about any suggestions or concerns.
> 
> I should make a pull request with this initial patchset soon
> 
> Thank you
> 
> -- 
> Bruno Dilly
> ProFUSION embedded systems
> http://profusion.mobi
> --
> 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


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


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

Re: [E-devel] Edje multiseat support

[The Rasterman]

On Fri, 2 Dec 2016 14:54:20 -0200 Bruno Dilly  said:

> Hi folks,
> 
> now that multiseat is supported up to Evas, we’re working on Edje.
> 
> 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”.
> 
> Please let me know about any suggestions or concerns.
> 
> I should make a pull request with this initial patchset soon

wait... so seats can be named... udev rules. so lets say i have seats:

bob
jane

i get signals like:

mouse,in,bob
mouse,out,jane

right?

so i ALSO get

mouse,in,seat1
mouse,out,seat2

? so i can write specific seat name handling signal stuff AND also have
generic? or... ?

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


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

Re: [E-devel] Edje multiseat support

[Gustavo Sverzut Barbieri]

On Fri, Dec 2, 2016 at 8:19 PM, Cedric BAIL  wrote:
> Hi,
>
> On Fri, Dec 2, 2016 at 8:54 AM, Bruno Dilly  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.

we did think a lot about it and it doesn't make sense, actually for
*theme* the only plausible solution is the sequential numbers.

OTOH, some *app* may want to persist or associate the actual seat the
with something else, like some username,credentials for a game... then
we offer the api to see the actual device "seat1" is.

Believe, me for theme if you get "button,1,xpto" in ".edc" you cannot
figure out what is "xpto" or do anything about it, programs don't get
their trigger names, for example :-)


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

Indeed it's not in the scope and text editing is a big bitch on its own.

Tom and Daniel can now get the events and test. If they can't
understand or miss something, they can ping us.


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

drag per seat was planned, like drag parts... used in scrollers.


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

It's doable as it's just early check & return... BUT I wonder how
someone would use it...



-- 
Gustavo Sverzut Barbieri
--
Mobile: +55 (16) 99354-9890

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

Re: [E-devel] Edje multiseat support

[Cedric BAIL]

Hi,

On Fri, Dec 2, 2016 at 8:54 AM, Bruno Dilly  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