Re: [E-devel] FW: FW: FW: FW: FW: FW: Propose a Eina_Path
+1
On Mon, 21 Nov 2016 at 02:11, Christopher Michael
wrote:
> On 11/20/2016 09:04 PM, Hermet Park wrote:
> > Make sense to me.
> >
> > If no one objects to efl_gfx_path, I will start with the conclusion soon.
> >
>
> +1
>
> dh
>
> > -Original Message-
> > From: "Cedric BAIL"
> > To: "Enlightenment developer list"<
> enlightenment-devel@lists.sourceforge.net>;
> > Cc:
> > Sent: 2016-11-18 (금) 04:39:09
> > Subject: Re: [E-devel] FW: FW: FW: FW: FW: FW: Propose a Eina_Path
> >
> > On Wed, Nov 16, 2016 at 5:25 PM, Hermet Park
> wrote:
> >> Well... If you argue only path should be an interface,
> >> I don't agree with you.
> >>
> >> I think path is nothing more than data structure & utility functions.
> >>
> >> If you say path is not a base data type, matrix, vector, curve and etc
> should not be in eina.
> >> They will harm consistency.
> >
> > Ok, try to see it the other way around. How would you define a matrix,
> > vector and a path in let say JS ? My take on this would be :
> >
> > v = { 0, 1, 2 }; m = { { 1, 0, 0 }, { 0, 1, 0 }, { 0, 0, 1} }; p = { {
> > MOVE_TO, CURVE_TO }, { 2, 2, 3, 4, 4, 5 } };
> >
> > You already see the problem here. vector and matrix are defined
> > mathematically. A path is not. Most language already have a math
> > package able to handle vector and matrix. If they don't well, we could
> > add matrix as an eo object. For path, you couldn't even have a
> > conversion from a string to a path without manually adding that API. P
> > is an object as it has a lot constructor and logic embedded in it, it
> > is not just a data structure nor is it a math primitive that is
> > supported in let say C++. So how do you expect bindings and C to have
> > the same consistent API with path ? How do you see a developer in JS
> > define a path ?
> >
> > Personnaly I would like to be able to do :
> >
> > p = new Path({ svg = "M 256,213 C 245,181 206,187 234,262 147,181
> > 169,71.2 233,18 220,56 235,81 283,88 285,78.7 286,69.3 288,60 289,61.3
> > 290,62.7 291,64 291,64 297,63 300,63 303,63 309,64 309,64 310,62.7
> > 311,61.3 312,60 314,69.3 315,78.7 317,88 365,82 380,56 367,18 431,71
> > 453,181 366,262 394,187 356,181 344,213 328,185 309,184 300,284
> > 291,184 272,185 256,213 Z" });
> > p = new Path({ .move_to(2, 1); .line_to(2, 2); .cubic_to(0, 1, 2, 3,
> > 4, 5, 6); });
> >
> > p.line_to(3, 4);
> >
> > This is something we would get for free with our current
> > efl_gfx_shape.eo that you want to move to eina. Please share your
> > vision on this.
> >
> > Cedric
> >
> >
> --
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
> --
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
>
>
>
>
> --
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] FW: FW: FW: FW: FW: FW: Propose a Eina_Path
On 11/20/2016 09:04 PM, Hermet Park wrote:
> Make sense to me.
>
> If no one objects to efl_gfx_path, I will start with the conclusion soon.
>
+1
dh
> -Original Message-
> From: "Cedric BAIL"
> To: "Enlightenment developer list";
> Cc:
> Sent: 2016-11-18 (금) 04:39:09
> Subject: Re: [E-devel] FW: FW: FW: FW: FW: FW: Propose a Eina_Path
>
> On Wed, Nov 16, 2016 at 5:25 PM, Hermet Park wrote:
>> Well... If you argue only path should be an interface,
>> I don't agree with you.
>>
>> I think path is nothing more than data structure & utility functions.
>>
>> If you say path is not a base data type, matrix, vector, curve and etc
>> should not be in eina.
>> They will harm consistency.
>
> Ok, try to see it the other way around. How would you define a matrix,
> vector and a path in let say JS ? My take on this would be :
>
> v = { 0, 1, 2 }; m = { { 1, 0, 0 }, { 0, 1, 0 }, { 0, 0, 1} }; p = { {
> MOVE_TO, CURVE_TO }, { 2, 2, 3, 4, 4, 5 } };
>
> You already see the problem here. vector and matrix are defined
> mathematically. A path is not. Most language already have a math
> package able to handle vector and matrix. If they don't well, we could
> add matrix as an eo object. For path, you couldn't even have a
> conversion from a string to a path without manually adding that API. P
> is an object as it has a lot constructor and logic embedded in it, it
> is not just a data structure nor is it a math primitive that is
> supported in let say C++. So how do you expect bindings and C to have
> the same consistent API with path ? How do you see a developer in JS
> define a path ?
>
> Personnaly I would like to be able to do :
>
> p = new Path({ svg = "M 256,213 C 245,181 206,187 234,262 147,181
> 169,71.2 233,18 220,56 235,81 283,88 285,78.7 286,69.3 288,60 289,61.3
> 290,62.7 291,64 291,64 297,63 300,63 303,63 309,64 309,64 310,62.7
> 311,61.3 312,60 314,69.3 315,78.7 317,88 365,82 380,56 367,18 431,71
> 453,181 366,262 394,187 356,181 344,213 328,185 309,184 300,284
> 291,184 272,185 256,213 Z" });
> p = new Path({ .move_to(2, 1); .line_to(2, 2); .cubic_to(0, 1, 2, 3,
> 4, 5, 6); });
>
> p.line_to(3, 4);
>
> This is something we would get for free with our current
> efl_gfx_shape.eo that you want to move to eina. Please share your
> vision on this.
>
> Cedric
>
> --
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> --
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] FW: FW: FW: FW: FW: FW: Propose a Eina_Path
Make sense to me.
If no one objects to efl_gfx_path, I will start with the conclusion soon.
-Original Message-
From: "Cedric BAIL"
To: "Enlightenment developer list";
Cc:
Sent: 2016-11-18 (금) 04:39:09
Subject: Re: [E-devel] FW: FW: FW: FW: FW: FW: Propose a Eina_Path
On Wed, Nov 16, 2016 at 5:25 PM, Hermet Park wrote:
> Well... If you argue only path should be an interface,
> I don't agree with you.
>
> I think path is nothing more than data structure & utility functions.
>
> If you say path is not a base data type, matrix, vector, curve and etc should
> not be in eina.
> They will harm consistency.
Ok, try to see it the other way around. How would you define a matrix,
vector and a path in let say JS ? My take on this would be :
v = { 0, 1, 2 }; m = { { 1, 0, 0 }, { 0, 1, 0 }, { 0, 0, 1} }; p = { {
MOVE_TO, CURVE_TO }, { 2, 2, 3, 4, 4, 5 } };
You already see the problem here. vector and matrix are defined
mathematically. A path is not. Most language already have a math
package able to handle vector and matrix. If they don't well, we could
add matrix as an eo object. For path, you couldn't even have a
conversion from a string to a path without manually adding that API. P
is an object as it has a lot constructor and logic embedded in it, it
is not just a data structure nor is it a math primitive that is
supported in let say C++. So how do you expect bindings and C to have
the same consistent API with path ? How do you see a developer in JS
define a path ?
Personnaly I would like to be able to do :
p = new Path({ svg = "M 256,213 C 245,181 206,187 234,262 147,181
169,71.2 233,18 220,56 235,81 283,88 285,78.7 286,69.3 288,60 289,61.3
290,62.7 291,64 291,64 297,63 300,63 303,63 309,64 309,64 310,62.7
311,61.3 312,60 314,69.3 315,78.7 317,88 365,82 380,56 367,18 431,71
453,181 366,262 394,187 356,181 344,213 328,185 309,184 300,284
291,184 272,185 256,213 Z" });
p = new Path({ .move_to(2, 1); .line_to(2, 2); .cubic_to(0, 1, 2, 3,
4, 5, 6); });
p.line_to(3, 4);
This is something we would get for free with our current
efl_gfx_shape.eo that you want to move to eina. Please share your
vision on this.
Cedric
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] FW: FW: FW: FW: FW: FW: Propose a Eina_Path
On Wed, Nov 16, 2016 at 5:25 PM, Hermet Park wrote:
> Well... If you argue only path should be an interface,
> I don't agree with you.
>
> I think path is nothing more than data structure & utility functions.
>
> If you say path is not a base data type, matrix, vector, curve and etc should
> not be in eina.
> They will harm consistency.
Ok, try to see it the other way around. How would you define a matrix,
vector and a path in let say JS ? My take on this would be :
v = { 0, 1, 2 }; m = { { 1, 0, 0 }, { 0, 1, 0 }, { 0, 0, 1} }; p = { {
MOVE_TO, CURVE_TO }, { 2, 2, 3, 4, 4, 5 } };
You already see the problem here. vector and matrix are defined
mathematically. A path is not. Most language already have a math
package able to handle vector and matrix. If they don't well, we could
add matrix as an eo object. For path, you couldn't even have a
conversion from a string to a path without manually adding that API. P
is an object as it has a lot constructor and logic embedded in it, it
is not just a data structure nor is it a math primitive that is
supported in let say C++. So how do you expect bindings and C to have
the same consistent API with path ? How do you see a developer in JS
define a path ?
Personnaly I would like to be able to do :
p = new Path({ svg = "M 256,213 C 245,181 206,187 234,262 147,181
169,71.2 233,18 220,56 235,81 283,88 285,78.7 286,69.3 288,60 289,61.3
290,62.7 291,64 291,64 297,63 300,63 303,63 309,64 309,64 310,62.7
311,61.3 312,60 314,69.3 315,78.7 317,88 365,82 380,56 367,18 431,71
453,181 366,262 394,187 356,181 344,213 328,185 309,184 300,284
291,184 272,185 256,213 Z" });
p = new Path({ .move_to(2, 1); .line_to(2, 2); .cubic_to(0, 1, 2, 3,
4, 5, 6); });
p.line_to(3, 4);
This is something we would get for free with our current
efl_gfx_shape.eo that you want to move to eina. Please share your
vision on this.
Cedric
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] FW: FW: FW: FW: FW: FW: Propose a Eina_Path
Well... If you argue only path should be an interface, I don't agree with you. I think path is nothing more than data structure & utility functions. If you say path is not a base data type, matrix, vector, curve and etc should not be in eina. They will harm consistency. I totally agree with raster that they are mostly used for graphics. and Path also. -Original Message- From: "Cedric BAIL" To: "Enlightenment developer list"; Cc: Sent: 2016-11-17 (목) 02:50:52 Subject: Re: [E-devel] FW: FW: FW: FW: FW: Propose a Eina_Path Hey Hermet, On Tue, Nov 15, 2016 at 10:20 PM, Hermet Park wrote: > Cedric, I got your point. > > If you are worrying the bindings of path, then what about others? Other structure don't need 20 functions to be created and populated. Even matrix, most language come with a math package to do whatever you want with them, the only thing really necessary is to be able to convert those structure back to the C layout that we expect. They are more part of the base data type you find everywhere like list, hash, array and friends. > I haven't planned the current eina structures bindings - vector, matrix, > etc, etc. > > Do we have plans about it? Do we need them in our API ? What API would be useful ? Vector, matrix and rectangle can be treated just as a simple structure with existing math package handling them, only C doesn't really provide that. Path is not the same. Without this 20 API you really won't go far creating your path. We are not talking about manipulating the path, but filling/setting it. As you are pointing out, you plan to use this Path information in more place in our API (Ector, Evas and Elementary), this means exposing it as part of our core API. Either bindings have to manually bind all the useful functions and keep track of them over time, or it is an Eo object and the internal representation doesn't matter to anyone. Which is actually the case. Cedric -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
