On Tue, Sep 13, 2016 at 8:17 PM, Cedric BAIL <cedric.b...@free.fr> wrote:
>> _Evas_Public_Data should contain a hash indexed by seat of focused
>> Evas_Objects. From “pd->focused” to “pd->focused[seat]”.
>
> Wouldn't it make sense to actually just give internally a number to
> each seat and use this as a mapping ? This way instead of a hash, you
> would have an array, which is nicer for just holding a pointer I
> think.
well, the number of seats or inputs will be so low that a hash may not
be the best approach. However seats are dynamic, come and go as you
hotplut them... so array index won't work, we need a linear search,
which should be very fast given the small set.
> Also I don't see anywhere in your proposal any event to notify
> the registration/unregistration of a seat. This will be necessary in
> the future for handling for example focus in elementary. There is an
> EFL_CANVAS_EVENT_DEVICE_CHANGED, but I don't think it match the use
> case. Would an EFL_CANVAS_EVENT_DEVICE_ADD and
> EFL_CANVAS_EVENT_DEVICE_DEL make sense to everyone ? Speaking of event
> you have also not talked about the focus event (object and canvas).
indeed we need something like that... likely all the way from ecore to
evas, or we auto-detect at evas level and callback when needed.
>> A function similar to evas_object_top_at_pointer_get(const Evas *e)
>> should be added. This new function will receive the Efl_Input_Device (the
>> seat) as argument. The old function should return the top Evas_Object
>> according to the default seat
>
> For what purpose ?
top_at_pointer_get() exists for some purpose... and it will remain
seat-less, so legacy works as expected.
as that function existed, we believe one with per-seat scope should
exist as well. If you disagree, then we do not add that.
>> evas_canvas_focus_get() should return the object focused by the default
>> seat.
>> -
>>
>> evas_canvas_pointer_canvas_xy_get() Should return the XY from the
>> default seat.
>> -
>>
>> evas_canvas_seat_pointer_canvas_xy_get() - Same thing as
>> evas_canvas_pointer_canvas_xy_get(), however it returns the XY based on
>> the
>> seat.
>
> It will be nice in code to refactor evas_canvas_pointer_canvas_xy_get
> to reuse evas_canvas_seat_pointer_canvas_xy_get. Also at this stage, I
> think none of the multi seat function should be part of the legacy API
> and the efl/eo interface should all be multi seat by default (If you
> pass NULL as a device, I think it should target the default seat).
hum... ok, so .eo is all seat, legacy is a manual wrapper where it
pass NULL. Makes sense.
>> evas_event_feed_hold - Will act in the default seat
>> -
>>
>> Add evas_event_feed_hold_by_seat() - Should we support this ?
>> -
>>
>> Add evas_device_seat_get(Evas_Device *dev);
>
> What will be the purpose of this function ?
basically Evas_Device * is Efl_Input_Device. It does have a
"device_type -> class". If class == seat, it's what you return,
otherwise you try your parent. It's a method to be implemented as a
recursion:
if o.device_type == seat then return o
else return evas_device_seat(o.parent)
The idea is to allow the possibility to cache that information if we
believe the resolution is too expensive.
Remember that Evas_Events* all carry "dev", which is the device that
generated the event. If you want the seat from that device, you should
call this function.
>> We may create a helper function in Efl_Input_Device::seat_get
>> -
>>
>> All evas_event_* functions will work on the top most seat. So in order
>> to add an event for ‘seat 1’ one should do: evas_device_push(evas,
>> seatOne); evas_event_*(); evas_device_pop(evas);
>
> evas_event functions are legacy only and mostly used internaly. I
> think we can just go with extending them and refactor the old version
> to call the new version with a NULL for seat.
nice, but I don't see the new functions being used, just the legacy
:-D Or am I mistaken? Eventually to keep the push/pop working as it
will be needed by legacy is more guaranteed to work, then we can
review that at the end?
/me is afraid to reach problems such as Efl_Loop_Fd (see
efl_net_dialer_http.c comments).
>> ecore_evas_x11_vnc_server_enabled(Ecore_Evas *ee, bool enable); -> This
>> will enable vnc server for the ecore_evas x11 module.
>
> Hum, why not the following instead of 3 differents functions :
>
> Ecore_Evas_VNC_Handler *ecore_evas_vnc_server_add(Ecore_Evas *ee,
> const char *addr, int port, Cb accept_cb);
> void ecore_evas_vnc_server_del(Ecore_Evas_VNC_Handler *h);
ok, makes sense... except to return the handle. There should be only
one vnc per canvas, or it will blow...
>> A callback will be created in order to notify the ecore_evas_x11 backend
>> with the modified pixels. This will be used to properly draw the VNC
>> remote
>> screen.
>
> I am working on Efl_Canvas_Output (in Evas). This enable the
> possibility to define specific output from a canvas and you can have
> multiple output at the same time. If no output is set, we have the
> same behavior as today. If an output is set, it will only render the
> part of the canvas covered by that output. Each output is backend
> specific and can be extended by some custom engine info, but if no
> engine information is provided, it will just create a buffer. An
> output is also always also providing an Efl.Gfx.Buffer API and allow
> to get pixels back (I only plan to implement it for software backend
> at the moment, but it could be extended for OpenGL backend later).
>
> The use case for this feature are multi screen support in Wayland (and
> maybe improving the X one by limiting the size of the output to each
> screen instead of a max of both), screen casting, wireless display and
> remote display. I should be done by end of next week if everything
> goes as planned.
ok, if it work then we can change to that. However the callback
mentioned here works ass you can see in the test repo, so we'll keep
using that for a while.
Also, be aware of the thread/async render... and the eoid resolution
changes done by raster.
--
Gustavo Sverzut Barbieri
--------------------------------------
Mobile: +55 (16) 99354-9890
------------------------------------------------------------------------------
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
