Re: [E-devel] FW: FW: FW: FW: FW: FW: Propose a Eina_Path

[Christopher Michael]

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

[Hermet Park]

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] [RFC] Ecore_Getopt STORE_DEF_* is strange

[Jean Guyomarc'h]

pong,

yeah sorry, I should have answered earlier but was pre-empted by other things.

Maybe I didn't understand correctly what you meant, but adding a new
field in Ecore_Getopt_Desc_Arg_Requirement (which btw, I don't see how
it would be ORed, as nothing in this enum can be meaningfully OR'ed,
because the existing values are 0, 1 and 3) would led to a "huge"
amount of code being written, like writing again the STORE_DEF macros
in something like STORE_DEF_VAL. By "huge",

If that's what you have in mind, I'll propose a new version (I'll go
through phab for this).

Best regards,

Jean


On Fri, Nov 18, 2016 at 12:32 PM, Gustavo Sverzut Barbieri
 wrote:
> ping?
>
> I can help with code, but at least need the better macro names :-)
>
> On Sun, Nov 13, 2016 at 11:11 AM, Gustavo Sverzut Barbieri
>  wrote:
>>
>>
>> Em sexta-feira, 11 de novembro de 2016, Jean Guyomarc'h
>>  escreveu:
>>>
>>> Hi all,
>>>
>>> I was using Ecore_Getopt with the STORE_DEF_* feature and noticed
>>> something I find quite strange, I could qualify as disturbing. The
>>> default storage thing seems very odd.
>>>
>>> (1) Values associated to optional parameters are not handled properly
>>>
>>> If you run the example, with minimal required arguments (e.g.
>>> ./src/examples/ecore/ecore_getopt_example string 33 banana zz), you
>>> will get the following (snipped):
>>>
>>> default-string = (null)
>>> default-bool = false
>>> default-short = 0
>>> default-int = 0
>>> default-long = 0
>>> default-unsigned-short = 0
>>> default-unsigned-int = 0
>>> default-unsigned-long = 0
>>> default-double = 0.00
>>>
>>> The default -* things are values that are supposed to be default
>>> values. And they are all wrong. This is even specified in the
>>> automatic help of the same program (snipped):
>>>
>>>   --default-string[=DEFAULT-STRING]
>>>   Store a single string.
>>>   Type: STR. Default: default-string-value.
>>>   --default-bool[=DEFAULT-BOOL]
>>>   Store a single boolean.
>>>   Type: BOOL. Default: true.
>>>   --default-short[=DEFAULT-SHORT]
>>>   Store a single short.
>>>   Type: SHORT. Default: 123.
>>>   --default-int[=DEFAULT-INT]
>>>   Store a single integer.
>>>   Type: INT. Default: 1234.
>>>   --default-long[=DEFAULT-LONG]
>>>   Store a single long integer.
>>>   Type: LONG. Default: 12345.
>>>   --default-unsigned-short[=DEFAULT-UNSIGNED-SHORT]
>>>   Store a single unsigned short integer.
>>>   Type: USHORT. Default: 123.
>>>   --default-unsigned-int[=DEFAULT-UNSIGNED-INT]
>>>   Store a single unsigned integer.
>>>   Type: UINT. Default: 1234.
>>>   --default-unsigned-long[=DEFAULT-UNSIGNED-LONG]
>>>   Store a single unsigned long integer.
>>>   Type: ULONG. Default: 12345.
>>>   --default-double[=DEFAULT-DOUBLE]
>>>   Store a single double.
>>>   Type: DOUBLE. Default: 12.345000.
>>>
>>> Every single use of the STORE_DEF stuff (in Ecore_Getopt) I've seen
>>> was to manually assign the variable containing the default value to
>>> the default value.
>>>
>>
>> My bad, I wrote and was bitten by it some times. But the idea and why I
>> didn't change it is because it is the default VALUE if the value is not
>> specified, but the option switch must be used.
>>
>> Like --default-double (instead of --default-long=123) used default specified
>> in the macro. But if you didn't specify the switch, nothing is assigned and
>> you simply use the variable with preset value.
>>
>>
>>
>>>
>>> To illustrate this, one typically mentions the default value in the
>>> Ecore_Getopt descriptor:
>>>
>>> ECORE_GETOPT_STORE_DEF_SHORT(0, "default-short", "Store a single short",
>>> 123),
>>>
>>> and pass this identical value to the Ecore_Getopt_Value thing:
>>>
>>> short def_val = 123; /* << Same than above */
>>> Ecore_Getopt_Value values[] = {
>>>  ECORE_GETOPT_VALUE_SHORT(_val),
>>> };
>>>
>>>
>>> This behaviour seems very wrong to me, because the implementation of
>>> the default value is not left to the getopt but up to the developer.
>>> And the developer should not do that. It should provide the default
>>> value to the getopt (what it already does) and that's it.
>>> If it (mistakenly) affects to the 'def_val' variable in our previous
>>> example something different than what it has wirtten in the getopt
>>> descriptor, the help and the actual default value will mismatch.
>>> That's actually the case in the ecore_getopt example.
>>>
>>> The code tht the developer has to write should just be:
>>>
>>> short def_val; /* << default value, automatically assigned,