Page MenuHomePhabricator

efl_gfx_path: path property
Open, NormalPublic


The path property of efl_gfx_path uses ptr() in a wrong way.
In C a array can be described with a pointer and a length. But there is no sane way to bind that in a arbitary langue from the .eo file.
This API should either use array<> or iterator<> or slice<ubyte>.

bu5hm4n created this task.Apr 20 2020, 12:47 AM
bu5hm4n triaged this task as Normal priority.
Hermet added a subscriber: Hermet.Apr 20 2020, 1:02 AM

will have a look.

jsuya added a subscriber: jsuya.May 20 2020, 11:45 PM

HI :) I did a little check to solve this.
I understand why you should replace void * with array <> or iterator <>....
However, efl_gfx_path uses the data transmitted as parameters from user side and does not manage path memory separately.
If this is changed, the user who has used the existing API or the legacy API must create and pass the array type data. or legacy path apis manage to array memory.
I think, we are not ready for that yet. The path is used in many places.

Please let me know if you have any good ideas for changing path property.

Hi, thank you for coming back to this.
As a general note:

In case the API does not manage the memory itself, then you can simply use a iterator<> or accessor<> which will leave the memory management to the user side of the API, the implementation then simply uses eina_accessor API to access it.
In case the API *does* manage the memory itself, then you can simply use a eina_array, and replace the data with the passed pointer, as well as the size of the container. The implentation then simply uses eina_array API.

One of those two solutions is needed here, and i think this is solvable with what we have right now ... (If not, can you explain again?, then i did not understand it yet :) )