Re: [E-devel] EFL interface, what's left to be done

[Tom Hacohen]

On 24/09/16 02:59, Cedric BAIL wrote:
> On Thu, Sep 22, 2016 at 4:35 AM, Tom Hacohen  wrote:
>> On 22/09/16 00:34, Cedric BAIL wrote:
>>> On Wed, Sep 21, 2016 at 1:46 AM, Tom Hacohen  wrote:
 On 19/09/16 23:33, Cedric BAIL wrote:
> On Mon, Sep 19, 2016 at 2:48 PM, Tom Hacohen  wrote:
>> We haven't agreed on merging Eo, Efl and Ecore. I'm actually pretty much
>> against it.
>
> There was a thread weeks ago. You indeed didn't take part of that
> discussion, but everyone else involved in that thread was ok. Actually
> the discussion evolved more into a what else to merge in. So their was
> an agreement before this email.

 Sorry, I missed that thread. What was the topic?
>>>
>>> Merging eo, efl and ecore. Like in the title :-)
>>
>> I remember that thread now, I misunderstood what you meant by merging
>> when you said it back then, and now with your promise inside lib/eo/ I
>> understand what you meant, and I'm very much against it.
>>
>> Let me clarify what I mean compared to my understanding of what you
>> mean. What I mean is what I thought was discussed in that thread.
>> I'm fine with:
>> Linking everything into one big fat ugly libefl.so (would rather not,
>> but OKish with that).
>> Having Efl.h that includes Eo.h, Elementary.h and etc.
>> Having an efl_init() and an efl_shutdown() that call them all.
>
> With EFL_MAIN, you don't need anymore to do any _init/_shutdown. Just
> for reference.
>
>> But if you think about it, it's essentially what we have in elementary.
>> It does all of the above except for the one binary linked together.
>> Which I'm mostly OK with (although see Marcel's comment about eo_debug
>> about which I forgot. Modularity has many advantages).
>>
>> What I'm *not* OK with:
>> Creating interdependency between the libraries and essentially making
>> libefl.so Ecore 2.0. One place to store everything. Units make a lot of
>> sense, of the advantages have been discussed above. My eo_debug trick
>> (which is ready, I just need to enable it, again, see marcel's email for
>> details) requires this separation.
>
> Saw it, it's neat. Question, why limitting it to eo ? Would be quite
> useful to also turn on more debug in eina, no ?
>
> 

Would maybe be useful for others. In addition, I retract my previous 
statement, there's no reason why it wouldn't work (I elaborated a bit 
more in my email from a few minutes ago).

>
 Or without joking: people have been using Eo without ecore and without
 Efl.Object. One example is Mike in E (reverted now because Eo was
 undeclared stable). You'll probably end up using Ecore in the same app,
 but again, everything you can say here you can say about Eina too.
>>>
>>> Do we have any example of an application that use Eo without Ecore or
>>> Efl today ?
>>
>> edje_cc, expedite, erigo-cli, clouseau-launcher (not the gui) and etc,
>> all depend on Eo and not on graphics. As for Ecore: I'm actually not
>> sure, some probably use ecore for networking, but it doesn't matter,
>> that's just a convenience that happened to be relevant for this case.
>> Sort of: if you can afford to use something that makes your life a bit
>> easier, why not.
>
> All of the above example do use ecore and where kind of my point.
>
 By "clean" I mean "isolated" or "untainted by its users up the stack".
 (see next comment for more info).

> I think that your disagreement about merging is only and just because
> you do not want to make asynchronous request a core feature of EFL.
> The rest is mostly rhetoric. Could you please explain why you have so
> much resistance to it being rolled into more place in efl ?

 That is exactly the reason (was I hiding it?), but not only, and one
 example of not "clean".

 A while back I was giving you some flack for not writing tests for a
 component of the EFL and cited Eo as an example of getting high test
 coverage. You then laughed it off and said something in the lines of
 "it's easier to test because it's smaller and not async" or something
 like that.
 **THAT IS EXACTLY MY POINT.**
  From my experience (and I guess the industry's collective experience),
 having small separate units make quality assurance easier, units more
 testable (because you can easily unit test) and the code easier to 
 maintain.
>>>
>>> In my opinion there is a lot of code in Eo that is far from nice to
>>> read and easy to maintain. First example is how intricate our pointer
>>> infrastructure is in eo and how little it makes sense. I have to go
>>> back at eina_safepointer, but there is seriously no justification for
>>> that. Especially when it hasn't help us catch thread safety bugs for
>>> example. So I agree with your small unit, but small unit has nothing
>>> todo as per library, it has to do with how we divide things between
>>> functions and files.
>>
>> No, it 

Re: [E-devel] EFL interface, what's left to be done

[Tom Hacohen]

On 24/09/16 10:07, marcel-hollerb...@t-online.de wrote:
> On Fri, Sep 23, 2016 at 06:59:14PM -0700, Cedric BAIL wrote:
>> On Thu, Sep 22, 2016 at 4:35 AM, Tom Hacohen  wrote:
>>> On 22/09/16 00:34, Cedric BAIL wrote:
 On Wed, Sep 21, 2016 at 1:46 AM, Tom Hacohen  wrote:
> On 19/09/16 23:33, Cedric BAIL wrote:
>> On Mon, Sep 19, 2016 at 2:48 PM, Tom Hacohen  wrote:
>>> We haven't agreed on merging Eo, Efl and Ecore. I'm actually pretty much
>>> against it.
>>
>> There was a thread weeks ago. You indeed didn't take part of that
>> discussion, but everyone else involved in that thread was ok. Actually
>> the discussion evolved more into a what else to merge in. So their was
>> an agreement before this email.
>
> Sorry, I missed that thread. What was the topic?

 Merging eo, efl and ecore. Like in the title :-)
>>>
>>> I remember that thread now, I misunderstood what you meant by merging
>>> when you said it back then, and now with your promise inside lib/eo/ I
>>> understand what you meant, and I'm very much against it.
>>>
>>> Let me clarify what I mean compared to my understanding of what you
>>> mean. What I mean is what I thought was discussed in that thread.
>>> I'm fine with:
>>> Linking everything into one big fat ugly libefl.so (would rather not,
>>> but OKish with that).
>>> Having Efl.h that includes Eo.h, Elementary.h and etc.
>>> Having an efl_init() and an efl_shutdown() that call them all.
>>
>> With EFL_MAIN, you don't need anymore to do any _init/_shutdown. Just
>> for reference.
>>
>>> But if you think about it, it's essentially what we have in elementary.
>>> It does all of the above except for the one binary linked together.
>>> Which I'm mostly OK with (although see Marcel's comment about eo_debug
>>> about which I forgot. Modularity has many advantages).
>>>
>>> What I'm *not* OK with:
>>> Creating interdependency between the libraries and essentially making
>>> libefl.so Ecore 2.0. One place to store everything. Units make a lot of
>>> sense, of the advantages have been discussed above. My eo_debug trick
>>> (which is ready, I just need to enable it, again, see marcel's email for
>>> details) requires this separation.
>>
>> Saw it, it's neat. Question, why limitting it to eo ? Would be quite
>> useful to also turn on more debug in eina, no ?
>
> For the same reason as why there are different log domains, if i have a issue
> with eo ref stuff, i would not like to get the complete output of ecore/eina.
>

First of all, as Carsten said, we can solve it with domains, but also, 
as long as we don't create inter-dependency between ecore and Eo, that 
is keep Eo isolated even if in the same binary (which is what I care 
about), then we could just ld_preload a debug libeo.so that would only 
modify eo.

--
Tom


--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EFL interface, what's left to be done

[The Rasterman]

On Mon, 26 Sep 2016 16:24:36 -0300 Gustavo Sverzut Barbieri
 said:

> On Fri, Sep 23, 2016 at 11:03 PM, Carsten Haitzler 
> wrote:
> > On Wed, 21 Sep 2016 11:10:00 -0300 Gustavo Sverzut Barbieri
> >  said:
> >
> >> On Wed, Sep 21, 2016 at 5:26 AM, Tom Hacohen  wrote:
> >> [...]
> >> >> promise/future should be first-class citizen... as well as iterator
> >> >> and the likes. There is a start already, but refinement is really
> >> >> needed, like returning an iterator should handle warn_unused, free,
> >> >> own... Promise should have its own callback signature, simplified for
> >> >> the user.
> >> >>
> >> >
> >> > They can, be, but they will just be provided by Eo. There's no need for
> >> > any special treatment in Eo.
> >> >
> >> > Promise signature: you don't need to do it in Eo. I mean, you can add a
> >> > special type in Eolian, but Eo itself need not be aware. Also, I
> >> > disagree.
> >>
> >> Do you mean still use Eo's events to dispatch promises?
> >
> > yes. when we had eina_promises i instantly just c'd the eo event cb to
> > write a success and failure handler and "boom type mismatch" ... wtf? i now
> > had to go look it up. PAIN POINT right out of the box.
> >
> > 90% of the time people only will care about success or failure. the other
> > 10% they want the value IN the promise. you can get that from the eo event
> > info. i actually think you just should "get" the value from the promise
> > object anyway as it stores it...
> 
> why is that? I know our APIs, particularly Evas and Elementary worked
> around the 'void *event' signatures by producing no "value" in the
> callback, instead forcing you to query that yourself. Like "canvas
> resized", then you must query the information "whats the new size?".
> 
> But if promise delivers the result in a nice way, we should be
> providing more values as payload.

promises do deliver values in the event info. in there... but i just dislike
this when you can query the promise itself for that in the cb or at any time in
the same way inside or outside that cb.

> >> I don't get why Efl.Promise is an Eo at all. Looking at the code shows
> >> now hints of benefits. Asking Cedric leads me to an awful answer...
> >> :-/
> >
> > because when it was an eina_promise it did everything an eo object did. it
> > had event callbacks (succeed/fail), it had progress event callbacks, it
> > stored values, could be ref and unreffed, and more and more. it looked
> > exactly like an eo object but just was an eina promise with its own custom
> > api instead. it just made no sense. there is a whole big long thread on
> > this in history you missed. you might weant to go back a few months for
> > "promises" subjects and see.
> 
> this is because, in my opinion, they tried to do too much for too
> little value. Allowing multiple then callbacks for a single promise is
> like that, you need a list of promises, you need to keep account if
> you're walking the list... if the promise was deleted from a cb, etc.

well the referencing was needed so you can cancel a promise as you now need to
store it as an object/handle to access later to cancel it. so cancellation
really created the need for it to be an object. so it shouldbe a real object,
so if i delete the promise it is canceled and then i can attach it as a child
object to my parent so if parent is deleted the promise is too thus cancelling
the action i no longer need with no extra code from me. :)

> if it was kept simple as in other implementations "1 promise = 1 then
> + 1 error", it would be much, much simpler. There is no ref, no
> unref... If an object returns a promise, the object itself will have
> to keep the pointer to deliver an output value (even if "void", to say
> it was fulfilled), thus you know when you get cancelled, and you know
> when you fulfill or reject.
> 
> There are 2 PoV to that: promise returners and users.
> 
> returners, or objects that return a promise, will create it and either
> fulfill or or reject it. They can pass one CB to be informed if the
> user cancelled the promise as its not needed anymore. The returner
> does all the memory allocation and free.
> 
> users are those that do "then" and "else" (or "on error"). Then is
> called upon fulfillment. Else (or on error) is called upon rejection.
> The only operation an user can do on a promise is to cancel it (which
> will report back to "returner" as per above). No memory management on
> the promise itself is done. Calling "cancel"  will call its own
> "else/on error".

and this is what REALLY necessitates an object. promises are objects in js for
example.

actually. i don't want to re-hash this thread. go back to the original one on
promises. :)

> >> The promise thing should only be a thin layer that forces a clear
> >> pattern: wait for data, deliver data or call failure. I don't get why
> >> in the other thread people were talking about references in 

Re: [E-devel] EFL interface, what's left to be done

[Gustavo Sverzut Barbieri]

On Fri, Sep 23, 2016 at 11:03 PM, Carsten Haitzler  wrote:
> On Wed, 21 Sep 2016 11:10:00 -0300 Gustavo Sverzut Barbieri
>  said:
>
>> On Wed, Sep 21, 2016 at 5:26 AM, Tom Hacohen  wrote:
>> [...]
>> >> promise/future should be first-class citizen... as well as iterator
>> >> and the likes. There is a start already, but refinement is really
>> >> needed, like returning an iterator should handle warn_unused, free,
>> >> own... Promise should have its own callback signature, simplified for
>> >> the user.
>> >>
>> >
>> > They can, be, but they will just be provided by Eo. There's no need for
>> > any special treatment in Eo.
>> >
>> > Promise signature: you don't need to do it in Eo. I mean, you can add a
>> > special type in Eolian, but Eo itself need not be aware. Also, I disagree.
>>
>> Do you mean still use Eo's events to dispatch promises?
>
> yes. when we had eina_promises i instantly just c'd the eo event cb to
> write a success and failure handler and "boom type mismatch" ... wtf? i now
> had to go look it up. PAIN POINT right out of the box.
>
> 90% of the time people only will care about success or failure. the other 10%
> they want the value IN the promise. you can get that from the eo event info. i
> actually think you just should "get" the value from the promise object anyway
> as it stores it...

why is that? I know our APIs, particularly Evas and Elementary worked
around the 'void *event' signatures by producing no "value" in the
callback, instead forcing you to query that yourself. Like "canvas
resized", then you must query the information "whats the new size?".

But if promise delivers the result in a nice way, we should be
providing more values as payload.



>> I don't get why Efl.Promise is an Eo at all. Looking at the code shows
>> now hints of benefits. Asking Cedric leads me to an awful answer...
>> :-/
>
> because when it was an eina_promise it did everything an eo object did. it had
> event callbacks (succeed/fail), it had progress event callbacks, it stored
> values, could be ref and unreffed, and more and more. it looked exactly like 
> an
> eo object but just was an eina promise with its own custom api instead. it 
> just
> made no sense. there is a whole big long thread on this in history you missed.
> you might weant to go back a few months for "promises" subjects and see.

this is because, in my opinion, they tried to do too much for too
little value. Allowing multiple then callbacks for a single promise is
like that, you need a list of promises, you need to keep account if
you're walking the list... if the promise was deleted from a cb, etc.

if it was kept simple as in other implementations "1 promise = 1 then
+ 1 error", it would be much, much simpler. There is no ref, no
unref... If an object returns a promise, the object itself will have
to keep the pointer to deliver an output value (even if "void", to say
it was fulfilled), thus you know when you get cancelled, and you know
when you fulfill or reject.

There are 2 PoV to that: promise returners and users.

returners, or objects that return a promise, will create it and either
fulfill or or reject it. They can pass one CB to be informed if the
user cancelled the promise as its not needed anymore. The returner
does all the memory allocation and free.

users are those that do "then" and "else" (or "on error"). Then is
called upon fulfillment. Else (or on error) is called upon rejection.
The only operation an user can do on a promise is to cancel it (which
will report back to "returner" as per above). No memory management on
the promise itself is done. Calling "cancel"  will call its own
"else/on error".





>> The promise thing should only be a thin layer that forces a clear
>> pattern: wait for data, deliver data or call failure. I don't get why
>> in the other thread people were talking about references in promises,
>> inheritance, etc.
>
> that's not what they were. they were full on objects with referencing and
> lifetimes etc. and reality is they actually need to be as you need to keep the
> promise handle around so you ca CANCEL it. there are cancel methods. this
> requires a lifetime and referencing. thus. eo objects.

not really, see above.

The API for promise returner is simple 3 methods:

Efl_Promise *efl_promise_new();
efl_promise_fulfill(p, value); //does free
efl_promise_reject(p, error); //does free

The API for promise user is also simple:

   Efl_Promise *efl_promise_then(p, on_fulfill, on_reject, data);
   void efl_promise_cancel(p); //calls efl_promise_reject() and thus
on_reject() and frees the data.

no ref/unref, nothing complex. If there is a single CB per promise,
then its simple. If there are multiple CBs as Felipe/Cedric want,
you'd need to keep a "walking" counter + deleted flags to avoid
messing with the list while its being walked. I don't think its worth.


>> While the API is what it should be, it's PITA to use. If 

Re: [E-devel] EFL interface, what's left to be done

[The Rasterman]

On Sat, 24 Sep 2016 11:07:16 +0200 marcel-hollerb...@t-online.de said:

> On Fri, Sep 23, 2016 at 06:59:14PM -0700, Cedric BAIL wrote:
> > On Thu, Sep 22, 2016 at 4:35 AM, Tom Hacohen  wrote:
> > > On 22/09/16 00:34, Cedric BAIL wrote:
> > >> On Wed, Sep 21, 2016 at 1:46 AM, Tom Hacohen  
> > >> wrote:
> > >>> On 19/09/16 23:33, Cedric BAIL wrote:
> >  On Mon, Sep 19, 2016 at 2:48 PM, Tom Hacohen  wrote:
> > > We haven't agreed on merging Eo, Efl and Ecore. I'm actually pretty
> > > much against it.
> > 
> >  There was a thread weeks ago. You indeed didn't take part of that
> >  discussion, but everyone else involved in that thread was ok. Actually
> >  the discussion evolved more into a what else to merge in. So their was
> >  an agreement before this email.
> > >>>
> > >>> Sorry, I missed that thread. What was the topic?
> > >>
> > >> Merging eo, efl and ecore. Like in the title :-)
> > >
> > > I remember that thread now, I misunderstood what you meant by merging
> > > when you said it back then, and now with your promise inside lib/eo/ I
> > > understand what you meant, and I'm very much against it.
> > >
> > > Let me clarify what I mean compared to my understanding of what you
> > > mean. What I mean is what I thought was discussed in that thread.
> > > I'm fine with:
> > > Linking everything into one big fat ugly libefl.so (would rather not,
> > > but OKish with that).
> > > Having Efl.h that includes Eo.h, Elementary.h and etc.
> > > Having an efl_init() and an efl_shutdown() that call them all.
> > 
> > With EFL_MAIN, you don't need anymore to do any _init/_shutdown. Just
> > for reference.
> > 
> > > But if you think about it, it's essentially what we have in elementary.
> > > It does all of the above except for the one binary linked together.
> > > Which I'm mostly OK with (although see Marcel's comment about eo_debug
> > > about which I forgot. Modularity has many advantages).
> > >
> > > What I'm *not* OK with:
> > > Creating interdependency between the libraries and essentially making
> > > libefl.so Ecore 2.0. One place to store everything. Units make a lot of
> > > sense, of the advantages have been discussed above. My eo_debug trick
> > > (which is ready, I just need to enable it, again, see marcel's email for
> > > details) requires this separation.
> > 
> > Saw it, it's neat. Question, why limitting it to eo ? Would be quite
> > useful to also turn on more debug in eina, no ?
> 
> For the same reason as why there are different log domains, if i have a issue 
> with eo ref stuff, i would not like to get the complete output of ecore/eina.

a problem solvable with ... log domains :)

> > 
> > 
> > 
> > >>> Or without joking: people have been using Eo without ecore and without
> > >>> Efl.Object. One example is Mike in E (reverted now because Eo was
> > >>> undeclared stable). You'll probably end up using Ecore in the same app,
> > >>> but again, everything you can say here you can say about Eina too.
> > >>
> > >> Do we have any example of an application that use Eo without Ecore or
> > >> Efl today ?
> > >
> > > edje_cc, expedite, erigo-cli, clouseau-launcher (not the gui) and etc,
> > > all depend on Eo and not on graphics. As for Ecore: I'm actually not
> > > sure, some probably use ecore for networking, but it doesn't matter,
> > > that's just a convenience that happened to be relevant for this case.
> > > Sort of: if you can afford to use something that makes your life a bit
> > > easier, why not.
> > 
> > All of the above example do use ecore and where kind of my point.
> > 
> > >>> By "clean" I mean "isolated" or "untainted by its users up the stack".
> > >>> (see next comment for more info).
> > >>>
> >  I think that your disagreement about merging is only and just because
> >  you do not want to make asynchronous request a core feature of EFL.
> >  The rest is mostly rhetoric. Could you please explain why you have so
> >  much resistance to it being rolled into more place in efl ?
> > >>>
> > >>> That is exactly the reason (was I hiding it?), but not only, and one
> > >>> example of not "clean".
> > >>>
> > >>> A while back I was giving you some flack for not writing tests for a
> > >>> component of the EFL and cited Eo as an example of getting high test
> > >>> coverage. You then laughed it off and said something in the lines of
> > >>> "it's easier to test because it's smaller and not async" or something
> > >>> like that.
> > >>> **THAT IS EXACTLY MY POINT.**
> > >>>  From my experience (and I guess the industry's collective experience),
> > >>> having small separate units make quality assurance easier, units more
> > >>> testable (because you can easily unit test) and the code easier to
> > >>> maintain.
> > >>
> > >> In my opinion there is a lot of code in Eo that is far from nice to
> > >> read and easy to maintain. First example is how intricate our pointer
> > >> 

Re: [E-devel] EFL interface, what's left to be done

[marcel-hollerbach]

On Fri, Sep 23, 2016 at 06:59:14PM -0700, Cedric BAIL wrote:
> On Thu, Sep 22, 2016 at 4:35 AM, Tom Hacohen  wrote:
> > On 22/09/16 00:34, Cedric BAIL wrote:
> >> On Wed, Sep 21, 2016 at 1:46 AM, Tom Hacohen  wrote:
> >>> On 19/09/16 23:33, Cedric BAIL wrote:
>  On Mon, Sep 19, 2016 at 2:48 PM, Tom Hacohen  wrote:
> > We haven't agreed on merging Eo, Efl and Ecore. I'm actually pretty much
> > against it.
> 
>  There was a thread weeks ago. You indeed didn't take part of that
>  discussion, but everyone else involved in that thread was ok. Actually
>  the discussion evolved more into a what else to merge in. So their was
>  an agreement before this email.
> >>>
> >>> Sorry, I missed that thread. What was the topic?
> >>
> >> Merging eo, efl and ecore. Like in the title :-)
> >
> > I remember that thread now, I misunderstood what you meant by merging
> > when you said it back then, and now with your promise inside lib/eo/ I
> > understand what you meant, and I'm very much against it.
> >
> > Let me clarify what I mean compared to my understanding of what you
> > mean. What I mean is what I thought was discussed in that thread.
> > I'm fine with:
> > Linking everything into one big fat ugly libefl.so (would rather not,
> > but OKish with that).
> > Having Efl.h that includes Eo.h, Elementary.h and etc.
> > Having an efl_init() and an efl_shutdown() that call them all.
> 
> With EFL_MAIN, you don't need anymore to do any _init/_shutdown. Just
> for reference.
> 
> > But if you think about it, it's essentially what we have in elementary.
> > It does all of the above except for the one binary linked together.
> > Which I'm mostly OK with (although see Marcel's comment about eo_debug
> > about which I forgot. Modularity has many advantages).
> >
> > What I'm *not* OK with:
> > Creating interdependency between the libraries and essentially making
> > libefl.so Ecore 2.0. One place to store everything. Units make a lot of
> > sense, of the advantages have been discussed above. My eo_debug trick
> > (which is ready, I just need to enable it, again, see marcel's email for
> > details) requires this separation.
> 
> Saw it, it's neat. Question, why limitting it to eo ? Would be quite
> useful to also turn on more debug in eina, no ?

For the same reason as why there are different log domains, if i have a issue 
with eo ref stuff, i would not like to get the complete output of ecore/eina.

> 
> 
> 
> >>> Or without joking: people have been using Eo without ecore and without
> >>> Efl.Object. One example is Mike in E (reverted now because Eo was
> >>> undeclared stable). You'll probably end up using Ecore in the same app,
> >>> but again, everything you can say here you can say about Eina too.
> >>
> >> Do we have any example of an application that use Eo without Ecore or
> >> Efl today ?
> >
> > edje_cc, expedite, erigo-cli, clouseau-launcher (not the gui) and etc,
> > all depend on Eo and not on graphics. As for Ecore: I'm actually not
> > sure, some probably use ecore for networking, but it doesn't matter,
> > that's just a convenience that happened to be relevant for this case.
> > Sort of: if you can afford to use something that makes your life a bit
> > easier, why not.
> 
> All of the above example do use ecore and where kind of my point.
> 
> >>> By "clean" I mean "isolated" or "untainted by its users up the stack".
> >>> (see next comment for more info).
> >>>
>  I think that your disagreement about merging is only and just because
>  you do not want to make asynchronous request a core feature of EFL.
>  The rest is mostly rhetoric. Could you please explain why you have so
>  much resistance to it being rolled into more place in efl ?
> >>>
> >>> That is exactly the reason (was I hiding it?), but not only, and one
> >>> example of not "clean".
> >>>
> >>> A while back I was giving you some flack for not writing tests for a
> >>> component of the EFL and cited Eo as an example of getting high test
> >>> coverage. You then laughed it off and said something in the lines of
> >>> "it's easier to test because it's smaller and not async" or something
> >>> like that.
> >>> **THAT IS EXACTLY MY POINT.**
> >>>  From my experience (and I guess the industry's collective experience),
> >>> having small separate units make quality assurance easier, units more
> >>> testable (because you can easily unit test) and the code easier to 
> >>> maintain.
> >>
> >> In my opinion there is a lot of code in Eo that is far from nice to
> >> read and easy to maintain. First example is how intricate our pointer
> >> infrastructure is in eo and how little it makes sense. I have to go
> >> back at eina_safepointer, but there is seriously no justification for
> >> that. Especially when it hasn't help us catch thread safety bugs for
> >> example. So I agree with your small unit, but small unit has nothing
> >> todo as per library, 

Re: [E-devel] EFL interface, what's left to be done

[The Rasterman]

On Fri, 23 Sep 2016 18:59:14 -0700 Cedric BAIL  said:

> On Thu, Sep 22, 2016 at 4:35 AM, Tom Hacohen  wrote:
> > On 22/09/16 00:34, Cedric BAIL wrote:
> >> On Wed, Sep 21, 2016 at 1:46 AM, Tom Hacohen  wrote:
> >>> On 19/09/16 23:33, Cedric BAIL wrote:
>  On Mon, Sep 19, 2016 at 2:48 PM, Tom Hacohen  wrote:
> > We haven't agreed on merging Eo, Efl and Ecore. I'm actually pretty much
> > against it.
> 
>  There was a thread weeks ago. You indeed didn't take part of that
>  discussion, but everyone else involved in that thread was ok. Actually
>  the discussion evolved more into a what else to merge in. So their was
>  an agreement before this email.
> >>>
> >>> Sorry, I missed that thread. What was the topic?
> >>
> >> Merging eo, efl and ecore. Like in the title :-)
> >
> > I remember that thread now, I misunderstood what you meant by merging
> > when you said it back then, and now with your promise inside lib/eo/ I
> > understand what you meant, and I'm very much against it.
> >
> > Let me clarify what I mean compared to my understanding of what you
> > mean. What I mean is what I thought was discussed in that thread.
> > I'm fine with:
> > Linking everything into one big fat ugly libefl.so (would rather not,
> > but OKish with that).
> > Having Efl.h that includes Eo.h, Elementary.h and etc.
> > Having an efl_init() and an efl_shutdown() that call them all.
> 
> With EFL_MAIN, you don't need anymore to do any _init/_shutdown. Just
> for reference.
> 
> > But if you think about it, it's essentially what we have in elementary.
> > It does all of the above except for the one binary linked together.
> > Which I'm mostly OK with (although see Marcel's comment about eo_debug
> > about which I forgot. Modularity has many advantages).
> >
> > What I'm *not* OK with:
> > Creating interdependency between the libraries and essentially making
> > libefl.so Ecore 2.0. One place to store everything. Units make a lot of
> > sense, of the advantages have been discussed above. My eo_debug trick
> > (which is ready, I just need to enable it, again, see marcel's email for
> > details) requires this separation.
> 
> Saw it, it's neat. Question, why limitting it to eo ? Would be quite
> useful to also turn on more debug in eina, no ?

a combined libefl.so (that is eina+ecore+eo+efl) wouldnt stop this - build 2
libefl's and use LD_PRELOAD to switch. same exact thing. just the debug lib is
bigger with more unaffected code. in fact what cedric says makes sense as we
can expand debug to eina and the mainloop and more.

> 
> 
> >>> Or without joking: people have been using Eo without ecore and without
> >>> Efl.Object. One example is Mike in E (reverted now because Eo was
> >>> undeclared stable). You'll probably end up using Ecore in the same app,
> >>> but again, everything you can say here you can say about Eina too.
> >>
> >> Do we have any example of an application that use Eo without Ecore or
> >> Efl today ?
> >
> > edje_cc, expedite, erigo-cli, clouseau-launcher (not the gui) and etc,
> > all depend on Eo and not on graphics. As for Ecore: I'm actually not
> > sure, some probably use ecore for networking, but it doesn't matter,
> > that's just a convenience that happened to be relevant for this case.
> > Sort of: if you can afford to use something that makes your life a bit
> > easier, why not.
> 
> All of the above example do use ecore and where kind of my point.
> 
> >>> By "clean" I mean "isolated" or "untainted by its users up the stack".
> >>> (see next comment for more info).
> >>>
>  I think that your disagreement about merging is only and just because
>  you do not want to make asynchronous request a core feature of EFL.
>  The rest is mostly rhetoric. Could you please explain why you have so
>  much resistance to it being rolled into more place in efl ?
> >>>
> >>> That is exactly the reason (was I hiding it?), but not only, and one
> >>> example of not "clean".
> >>>
> >>> A while back I was giving you some flack for not writing tests for a
> >>> component of the EFL and cited Eo as an example of getting high test
> >>> coverage. You then laughed it off and said something in the lines of
> >>> "it's easier to test because it's smaller and not async" or something
> >>> like that.
> >>> **THAT IS EXACTLY MY POINT.**
> >>>  From my experience (and I guess the industry's collective experience),
> >>> having small separate units make quality assurance easier, units more
> >>> testable (because you can easily unit test) and the code easier to
> >>> maintain.
> >>
> >> In my opinion there is a lot of code in Eo that is far from nice to
> >> read and easy to maintain. First example is how intricate our pointer
> >> infrastructure is in eo and how little it makes sense. I have to go
> >> back at eina_safepointer, but there is seriously no justification for
> >> that. Especially when it hasn't 

Re: [E-devel] EFL interface, what's left to be done

[The Rasterman]

On Mon, 19 Sep 2016 21:46:36 + Andrew Williams  said:

> Hi Cedric,
> 
> Great list thanks :)
> 
> Along with all the breaking changes I thought I would throw a suggestion
> into the mix...
> How about we move non-core Elementary widgets out to an elm_extra library
> not in main efl? There is so much in there that we are struggling to add
> important stuff like tabs etc. If we could maintain a little less as a core
> group this might be the time?
> Also new widgets could start here rather than in efl...

we can't really SPLIT things out. at least legacy efl api widgets have to be
found in the same .so they were found in before. we can MERGE with symlinks but
can't split... :(

also if elm_extra is still part of the efl tree then it doesnt much matter as
it has to be maintained along with the rest. if it's totally split out we end
up with a mess of "well you basically have to also now build this elm extra
lib in addition to efl just to have working apps".

i do agre we have far too many widgets. some widgets we already marked for
"will not have eo api for them" so they are basically being left to rot in
legacy api only and then eventually for efl 2.0 dropped of course.

i really think for example we just need an efl.ui.media object and no image +
video + photocam + ... just one that displays some kind of media and what you
point is at and its mode determine what it does. :) others seem to love the
idea of specializing classes for everything (thus having LOTS of widgets).

> Cheers,
> Andy
> On Mon, 19 Sep 2016 at 22:06, Cedric BAIL  wrote:
> 
> > Hello everyone,
> >
> > So this email is going over what is left to be done to call EFL
> > interface done. Most of this require still discussion also. Here it
> > goes :
> >
> > - Merge Eo, Efl and Ecore
> > - Make efl_uri_set/efl_file_set asynchronous
> > - Convert Ecore_Exe to the new efl_io API
> > - Fixup efl/interface/*.eo to all be in the correct namespace
> > - Disable installation of evas/canvas/evas*.eo
> > - Convert edje to become efl_canvas_layout
> > - Update Edje with the new Text API
> > - Convert elm_layout to become efl_ui_layout
> > - Convert elm_widget to be an efl_ui_object of some sort
> > - Update all efl data model to use efl_future/efl_promise
> > - Add proper View and Controller for Genlist/Gengrid (see D3952 for some
> > ideas)
> > - There is still a large amount of .eo in elementary that are in elm
> > namespace. This shouldn't be installed nor appear anywhere in the
> > hierarchy.
> > - Finish porting some of the widget to Efl.Ui namespace (photocam,
> > index, entry, button, calendar, clock, menu, ...). This needs to be
> > clarified with some pending patch in phab.
> >
> > This are quite a large todo list to be done with, hopefully it will...
> > --
> > Cedric BAIL
> >
> >
> > --
> > ___
> > 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
> 


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


--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EFL interface, what's left to be done

[The Rasterman]

On Tue, 20 Sep 2016 01:14:32 -0300 Gustavo Sverzut Barbieri
 said:

> On Mon, Sep 19, 2016 at 7:33 PM, Cedric BAIL  wrote:
> > On Mon, Sep 19, 2016 at 2:48 PM, Tom Hacohen  wrote:
> >> We haven't agreed on merging Eo, Efl and Ecore. I'm actually pretty much
> >> against it.
> >
> > There was a thread weeks ago. You indeed didn't take part of that
> > discussion, but everyone else involved in that thread was ok. Actually
> > the discussion evolved more into a what else to merge in. So their was
> > an agreement before this email.
> >
> >> Eo is clean and hasn't been "polluted" by async, mainloop and etc. That's a
> >> good thing. This makes our infrastructure easier to test.
> >
> > Please define "clean" as it is a bit abstract to me here. What I am
> > looking for here is the minimal set of component I need to have
> > something useful. Is Eo useful by itself ? With just Efl.Object ? Sure
> > you could do C without the C library, but would you ?
> >
> > I think that your disagreement about merging is only and just because
> > you do not want to make asynchronous request a core feature of EFL.
> > The rest is mostly rhetoric. Could you please explain why you have so
> > much resistance to it being rolled into more place in efl ?
> 
> [...]
> 
> > I don't want to just compile them together. I want to merge there
> > headers. Make it just one library. Make efl.object, efl.future and
> > efl.loop one core. Obviously because I want to see efl as providing a
> > core asynchronous library with defined pattern. One asynchronous
> > pattern is "events", which is like an UDP broadcast (default
> > behavior)/multicast (with effort) solution. Efl.Future is more the
> > equivalent of a TCP connection. I think providing one without the
> > other is going to push for a world of broadcast solution which is not
> > always the right pattern. Maybe we should remove events support from
> > Eo to avoid this problem.
> 
> +1 fully agree with Cedric's rationale. Eo's purpose should be
> solely to serve Efl's use cases, which means asynchronous event driven
> programming.
> 
> promise/future should be first-class citizen... as well as iterator
> and the likes. There is a start already, but refinement is really
> needed, like returning an iterator should handle warn_unused, free,
> own... Promise should have its own callback signature, simplified for
> the user.
> 
> AND if possible, make eolian or a new tool to handle connections for
> us, if it was easy to declare objects with composition of
> events/promises, it would save us lots of typing and errors.

well ORIGINALLy my proposal was to have a preprocessor. use it instead of $CC
(and use it much like ccache/distcc. set $CC to "eflc gcc" or "eflc clang"
etc.) and this preprocessor would basically take c and EXTEND the ability of a
preprocessor (like c's cpp) to do better contextual code generation for us and
cut out footwork. the good thing is it requires no porting of code. existing c
just works. we can then ADD new things and change over time to uise the
code/time saving features that simplify our code. so yes - we'd create a hybrid
language of c + our own extensions via the preprocessor.

but everyone hates the idea so it didnt happen and won't. so give up on
this. :) generating c code you then have to edit is far messier as then you
have to edit/maintain 2 files - the template file and the generated one in
which you put the real code. but thats what everyone wanted. they want the
extra work to maintain "purity". :)


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


--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EFL interface, what's left to be done

[The Rasterman]

On Fri, 23 Sep 2016 20:09:01 +0200 Davide Andreoli 
said:

> 2016-09-22 8:55 GMT+02:00 Jean-Philippe André :
> 
> > Hi,
> >
> > On 22 September 2016 at 15:34, Davide Andreoli 
> > wrote:
> >
> > > 2016-09-22 0:45 GMT+02:00 Gustavo Sverzut Barbieri :
> > >
> > > > On Wed, Sep 21, 2016 at 11:33 AM, Tom Hacohen 
> > > wrote:
> > > > > On 21/09/16 15:10, Gustavo Sverzut Barbieri wrote:
> > > > >> On Wed, Sep 21, 2016 at 5:26 AM, Tom Hacohen 
> > > > wrote:
> > > > >> [...]
> > > >  promise/future should be first-class citizen... as well as
> > iterator
> > > >  and the likes. There is a start already, but refinement is really
> > > >  needed, like returning an iterator should handle warn_unused,
> > > free,
> > > >  own... Promise should have its own callback signature, simplified
> > > for
> > > >  the user.
> > > > 
> > > > >>>
> > > > >>> They can, be, but they will just be provided by Eo. There's no need
> > > for
> > > > >>> any special treatment in Eo.
> > > > >>>
> > > > >>> Promise signature: you don't need to do it in Eo. I mean, you can
> > > add a
> > > > >>> special type in Eolian, but Eo itself need not be aware. Also, I
> > > > disagree.
> > > > >>
> > > > >> Do you mean still use Eo's events to dispatch promises?
> > > > >
> > > > > Not necessarily, just use the same signature because it's a good one,
> > > > > it's extendable, it applies here too, and it's easier for bindings
> > this
> > > > way.
> > > >
> > > > It's a good one to who? It's a generic one, for sure, but that doesn't
> > > > make it a good one. Promises, for instance, will carry a value, but
> > > > it's not immediately available. Even for regular events I don't get
> > > > why the object must be fetched from the efl_event...
> > > >
> > >
> > > I'm with Gustavo here, reusing the same callback signature for event
> > > and promises don't seems to be a good idea, it just make the usage more
> > > confusing and more error prone. Having 2 different signature will make
> > > the separation line between events and promises more clear.
> > >
> >
> > I can hear Cedric screaming in despair on the other side of the planet.
> >
> > We argued that a single signature was better, as our different callback
> > signatures (ecore events, evas events. smart callbacks, ...) were one of
> > the pain points of using EFL. Now it's pretty clear some people want to
> > reintroduce this with promises vs. events. Gustavo missed these heated
> > arguments as he started working back on EFL after those long mail threads.
> > Same for why object is in Efl_Event rather than being in the argument list.
> >
> 
> For what I remember we discussed that all EVENTS must use the same
> signature, and I'm ok with that. But promises are different, they are not
> events.

they are events. there is a success and failure event. regardless having to
remember ANOTHER prototype is mental load and a pain. the whole point of eo was
to get rid of our mess of all these cb prototypes and have one single one. a
promise fail or succeed is a single event that is called at the end of the
lifetime of that promise - like a DEL event on any eo object when its deleted.

> But I agree with you that we are arguing too much without a clear view of
> what
> we have now and what we are going to implement wrt promises and future.
> At this point I'm also confused between future and promise... I highly
> suggest
> to write a wiki page with all the needed explanations and examples usage for
> both promise and future , so that we can discuss with a documented base.

i think splitting them is bad. just an object representing the "this thing
happens in the future" or the promise object... with a future and promise
INTERFACE. one is for the "user" or "consumer" of that promise, the other is
for the code that DRIVES the promise - ie tells the consumer when its failed or
succeeded. just don't use the interface (methods/api's) that are not
appropriate for your side of the promise/future.

in js its JUST a promise object for all of this.

> > To be fair, promises were supposed to carry a single value only, IOW
> > Efl_Event.info was supposed to be the value. No double cast. Thinking of
> > it, I'm not sure why "next" isn't in fact a property on the promise itself
> > (as it's Efl_Event.object), rather than being awkwardly passed in the event
> > info -- there may be a good reason. (see also efl_event_callback_stop).
> >
> > Anyway. I'll wait until I can see *exactly* how async operations (image
> > file_set in particular) work with promises. Too much arguing about unclear
> > details until that is done.
> >
> > --
> > Jean-Philippe André
> > 
> > --
> > ___
> > enlightenment-devel mailing list
> > 

Re: [E-devel] EFL interface, what's left to be done

[The Rasterman]

On Wed, 21 Sep 2016 11:10:00 -0300 Gustavo Sverzut Barbieri
 said:

> On Wed, Sep 21, 2016 at 5:26 AM, Tom Hacohen  wrote:
> [...]
> >> promise/future should be first-class citizen... as well as iterator
> >> and the likes. There is a start already, but refinement is really
> >> needed, like returning an iterator should handle warn_unused, free,
> >> own... Promise should have its own callback signature, simplified for
> >> the user.
> >>
> >
> > They can, be, but they will just be provided by Eo. There's no need for
> > any special treatment in Eo.
> >
> > Promise signature: you don't need to do it in Eo. I mean, you can add a
> > special type in Eolian, but Eo itself need not be aware. Also, I disagree.
> 
> Do you mean still use Eo's events to dispatch promises?

yes. when we had eina_promises i instantly just c'd the eo event cb to
write a success and failure handler and "boom type mismatch" ... wtf? i now
had to go look it up. PAIN POINT right out of the box.

90% of the time people only will care about success or failure. the other 10%
they want the value IN the promise. you can get that from the eo event info. i
actually think you just should "get" the value from the promise object anyway
as it stores it... 

> I don't get why Efl.Promise is an Eo at all. Looking at the code shows
> now hints of benefits. Asking Cedric leads me to an awful answer...
> :-/

because when it was an eina_promise it did everything an eo object did. it had
event callbacks (succeed/fail), it had progress event callbacks, it stored
values, could be ref and unreffed, and more and more. it looked exactly like an
eo object but just was an eina promise with its own custom api instead. it just
made no sense. there is a whole big long thread on this in history you missed.
you might weant to go back a few months for "promises" subjects and see.

> The promise thing should only be a thin layer that forces a clear
> pattern: wait for data, deliver data or call failure. I don't get why
> in the other thread people were talking about references in promises,
> inheritance, etc.

that's not what they were. they were full on objects with referencing and
lifetimes etc. and reality is they actually need to be as you need to keep the
promise handle around so you ca CANCEL it. there are cancel methods. this
requires a lifetime and referencing. thus. eo objects.

> >> AND if possible, make eolian or a new tool to handle connections for
> >> us, if it was easy to declare objects with composition of
> >> events/promises, it would save us lots of typing and errors.
> >>
> >>
> >
> > I'm not sure what you meant here.
> 
> the process of creating and object, setting its properties and
> connecting events is painful in C. We need to replicate the whole
> "_${METHOD}(efl_added, ${VALUE})"... for events it's even
> worse.

well efl future is already pretty good:

f = efl_file_set(obj, "blah". NULL);
efl_future_then(f, cb_success, cb_failure, obj);

sure - lambdas would allow the success/failure code to be inline like langs
like js/lua. we actually should consider using lambdapp just to make our own
efl c code more manageable. but either way that above is not that bad. if you
want to handle more (progress, make the promise cancellable safely like keeping
a ref or weak ref around ...) requires another line or 2. but this here isn't
bad for the common case of just success or failure.

> While the API is what it should be, it's PITA to use. If we could
> extend the generator to do those for us, we'd have to implement only
> high level functions. Like it does for C++ or Lua bindings, do to C
> "user code" (could also do C++/Lua user code as well). Example:
> 
> myapp.eou:  # eou = eo user
> 
> objects {
> xpto { /* creates an object called "xpto" */
>children {
>   window { /* window is part of xpto, it will be created using
> given type and properties */
>  type: Efl.Ui.Win;
>  constructor {
> type: Efl.Ui.Win.Type.basic;
> title: "hello world";
>  }
>  events { /* these will be connected for you, callback
> handlers are expanded based on event payload */
> resized @proxy; /* proxy = will forward this event as
> "xpto" using the same name */
> delete,request; /* user must implement the callback
> with handler */
>  }
>   }
>   box {
>  type: Efl.Ui.Box;
>   }
>   label1 {
>  type: Efl.Ui.Label;
>   }
>   label2 {
>  type: Efl.Ui.Label;
>   }
>   entry {
>  type: Efl.Ui.Entry;
>   }
>   }
> 
>connections {
>   entry: changed -> label2: text.set; /* somehow like Qt's
> signal connection */
>}
> 
>composition { /* basic method calls using other objects and constants
> */ box.pack_align(0.5, 0.5);
> 
>

Re: [E-devel] EFL interface, what's left to be done

[The Rasterman]

On Thu, 22 Sep 2016 15:55:33 +0900 Jean-Philippe André  said:

> Hi,
> 
> On 22 September 2016 at 15:34, Davide Andreoli 
> wrote:
> 
> > 2016-09-22 0:45 GMT+02:00 Gustavo Sverzut Barbieri :
> >
> > > On Wed, Sep 21, 2016 at 11:33 AM, Tom Hacohen 
> > wrote:
> > > > On 21/09/16 15:10, Gustavo Sverzut Barbieri wrote:
> > > >> On Wed, Sep 21, 2016 at 5:26 AM, Tom Hacohen 
> > > wrote:
> > > >> [...]
> > >  promise/future should be first-class citizen... as well as iterator
> > >  and the likes. There is a start already, but refinement is really
> > >  needed, like returning an iterator should handle warn_unused,
> > free,
> > >  own... Promise should have its own callback signature, simplified
> > for
> > >  the user.
> > > 
> > > >>>
> > > >>> They can, be, but they will just be provided by Eo. There's no need
> > for
> > > >>> any special treatment in Eo.
> > > >>>
> > > >>> Promise signature: you don't need to do it in Eo. I mean, you can
> > add a
> > > >>> special type in Eolian, but Eo itself need not be aware. Also, I
> > > disagree.
> > > >>
> > > >> Do you mean still use Eo's events to dispatch promises?
> > > >
> > > > Not necessarily, just use the same signature because it's a good one,
> > > > it's extendable, it applies here too, and it's easier for bindings this
> > > way.
> > >
> > > It's a good one to who? It's a generic one, for sure, but that doesn't
> > > make it a good one. Promises, for instance, will carry a value, but
> > > it's not immediately available. Even for regular events I don't get
> > > why the object must be fetched from the efl_event...
> > >
> >
> > I'm with Gustavo here, reusing the same callback signature for event
> > and promises don't seems to be a good idea, it just make the usage more
> > confusing and more error prone. Having 2 different signature will make
> > the separation line between events and promises more clear.
> >
> 
> I can hear Cedric screaming in despair on the other side of the planet.
> 
> We argued that a single signature was better, as our different callback
> signatures (ecore events, evas events. smart callbacks, ...) were one of
> the pain points of using EFL. Now it's pretty clear some people want to
> reintroduce this with promises vs. events. Gustavo missed these heated
> arguments as he started working back on EFL after those long mail threads.
> Same for why object is in Efl_Event rather than being in the argument list.
> 
> To be fair, promises were supposed to carry a single value only, IOW
> Efl_Event.info was supposed to be the value. No double cast. Thinking of
> it, I'm not sure why "next" isn't in fact a property on the promise itself
> (as it's Efl_Event.object), rather than being awkwardly passed in the event
> info -- there may be a good reason. (see also efl_event_callback_stop).
> 
> Anyway. I'll wait until I can see *exactly* how async operations (image
> file_set in particular) work with promises. Too much arguing about unclear
> details until that is done.

tbh efl_future should have a value_get to get it from the future. it should
ALSO have a progress_get that gets some double. this should be there either way
and store the last known progress or the value once success/failure is hit.
this makes it perfectly simple and clean. same with getting the next future -
get it from the future object.

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


--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EFL interface, what's left to be done

[The Rasterman]

On Mon, 19 Sep 2016 14:05:57 -0700 Cedric BAIL  said:

> Hello everyone,
> 
> So this email is going over what is left to be done to call EFL
> interface done. Most of this require still discussion also. Here it
> goes :
> 
> - Merge Eo, Efl and Ecore

should we merge libemile and libeet and libefl.so in too? definitely libefl.so
for sure

> - Make efl_uri_set/efl_file_set asynchronous
> - Convert Ecore_Exe to the new efl_io API
> - Fixup efl/interface/*.eo to all be in the correct namespace
> - Disable installation of evas/canvas/evas*.eo
> - Convert edje to become efl_canvas_layout
> - Update Edje with the new Text API
> - Convert elm_layout to become efl_ui_layout
> - Convert elm_widget to be an efl_ui_object of some sort
> - Update all efl data model to use efl_future/efl_promise
> - Add proper View and Controller for Genlist/Gengrid (see D3952 for some
> ideas)
> - There is still a large amount of .eo in elementary that are in elm
> namespace. This shouldn't be installed nor appear anywhere in the
> hierarchy.
> - Finish porting some of the widget to Efl.Ui namespace (photocam,
> index, entry, button, calendar, clock, menu, ...). This needs to be
> clarified with some pending patch in phab.

+ elm media widget (ala what terminology uses today to just display any media)
  ^^^ this depends on other elm widget changes to be finished really.
+ efl.loop i think should REALLY become an object and not a fake one like now
+ ecore_thread -> eo design (redesign it to be bi-directional for msging etc.
and just keep ecore_thread in legacy only) - if you do the efl.loop i'll be
happy to tackle this as i've been thinking about this for quite a while now.

> This are quite a large todo list to be done with, hopefully it will...
> -- 
> Cedric BAIL
> 
> --
> ___
> 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


--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EFL interface, what's left to be done

[Cedric BAIL]

On Thu, Sep 22, 2016 at 4:35 AM, Tom Hacohen  wrote:
> On 22/09/16 00:34, Cedric BAIL wrote:
>> On Wed, Sep 21, 2016 at 1:46 AM, Tom Hacohen  wrote:
>>> On 19/09/16 23:33, Cedric BAIL wrote:
 On Mon, Sep 19, 2016 at 2:48 PM, Tom Hacohen  wrote:
> We haven't agreed on merging Eo, Efl and Ecore. I'm actually pretty much
> against it.

 There was a thread weeks ago. You indeed didn't take part of that
 discussion, but everyone else involved in that thread was ok. Actually
 the discussion evolved more into a what else to merge in. So their was
 an agreement before this email.
>>>
>>> Sorry, I missed that thread. What was the topic?
>>
>> Merging eo, efl and ecore. Like in the title :-)
>
> I remember that thread now, I misunderstood what you meant by merging
> when you said it back then, and now with your promise inside lib/eo/ I
> understand what you meant, and I'm very much against it.
>
> Let me clarify what I mean compared to my understanding of what you
> mean. What I mean is what I thought was discussed in that thread.
> I'm fine with:
> Linking everything into one big fat ugly libefl.so (would rather not,
> but OKish with that).
> Having Efl.h that includes Eo.h, Elementary.h and etc.
> Having an efl_init() and an efl_shutdown() that call them all.

With EFL_MAIN, you don't need anymore to do any _init/_shutdown. Just
for reference.

> But if you think about it, it's essentially what we have in elementary.
> It does all of the above except for the one binary linked together.
> Which I'm mostly OK with (although see Marcel's comment about eo_debug
> about which I forgot. Modularity has many advantages).
>
> What I'm *not* OK with:
> Creating interdependency between the libraries and essentially making
> libefl.so Ecore 2.0. One place to store everything. Units make a lot of
> sense, of the advantages have been discussed above. My eo_debug trick
> (which is ready, I just need to enable it, again, see marcel's email for
> details) requires this separation.

Saw it, it's neat. Question, why limitting it to eo ? Would be quite
useful to also turn on more debug in eina, no ?



>>> Or without joking: people have been using Eo without ecore and without
>>> Efl.Object. One example is Mike in E (reverted now because Eo was
>>> undeclared stable). You'll probably end up using Ecore in the same app,
>>> but again, everything you can say here you can say about Eina too.
>>
>> Do we have any example of an application that use Eo without Ecore or
>> Efl today ?
>
> edje_cc, expedite, erigo-cli, clouseau-launcher (not the gui) and etc,
> all depend on Eo and not on graphics. As for Ecore: I'm actually not
> sure, some probably use ecore for networking, but it doesn't matter,
> that's just a convenience that happened to be relevant for this case.
> Sort of: if you can afford to use something that makes your life a bit
> easier, why not.

All of the above example do use ecore and where kind of my point.

>>> By "clean" I mean "isolated" or "untainted by its users up the stack".
>>> (see next comment for more info).
>>>
 I think that your disagreement about merging is only and just because
 you do not want to make asynchronous request a core feature of EFL.
 The rest is mostly rhetoric. Could you please explain why you have so
 much resistance to it being rolled into more place in efl ?
>>>
>>> That is exactly the reason (was I hiding it?), but not only, and one
>>> example of not "clean".
>>>
>>> A while back I was giving you some flack for not writing tests for a
>>> component of the EFL and cited Eo as an example of getting high test
>>> coverage. You then laughed it off and said something in the lines of
>>> "it's easier to test because it's smaller and not async" or something
>>> like that.
>>> **THAT IS EXACTLY MY POINT.**
>>>  From my experience (and I guess the industry's collective experience),
>>> having small separate units make quality assurance easier, units more
>>> testable (because you can easily unit test) and the code easier to maintain.
>>
>> In my opinion there is a lot of code in Eo that is far from nice to
>> read and easy to maintain. First example is how intricate our pointer
>> infrastructure is in eo and how little it makes sense. I have to go
>> back at eina_safepointer, but there is seriously no justification for
>> that. Especially when it hasn't help us catch thread safety bugs for
>> example. So I agree with your small unit, but small unit has nothing
>> todo as per library, it has to do with how we divide things between
>> functions and files.
>
> No, it has everything to do with interconnectivity of components. Small
> units mean: interdependency is allowed within that unit but not outside
> of it.

I don't see your problem at all. We have a lot of "independent" unit
tested properly in eina and eet. Would you have preferred to see eina
split for each data type ?

> Safepointer: 

Re: [E-devel] EFL interface, what's left to be done

[Davide Andreoli]

2016-09-22 8:55 GMT+02:00 Jean-Philippe André :

> Hi,
>
> On 22 September 2016 at 15:34, Davide Andreoli 
> wrote:
>
> > 2016-09-22 0:45 GMT+02:00 Gustavo Sverzut Barbieri :
> >
> > > On Wed, Sep 21, 2016 at 11:33 AM, Tom Hacohen 
> > wrote:
> > > > On 21/09/16 15:10, Gustavo Sverzut Barbieri wrote:
> > > >> On Wed, Sep 21, 2016 at 5:26 AM, Tom Hacohen 
> > > wrote:
> > > >> [...]
> > >  promise/future should be first-class citizen... as well as
> iterator
> > >  and the likes. There is a start already, but refinement is really
> > >  needed, like returning an iterator should handle warn_unused,
> > free,
> > >  own... Promise should have its own callback signature, simplified
> > for
> > >  the user.
> > > 
> > > >>>
> > > >>> They can, be, but they will just be provided by Eo. There's no need
> > for
> > > >>> any special treatment in Eo.
> > > >>>
> > > >>> Promise signature: you don't need to do it in Eo. I mean, you can
> > add a
> > > >>> special type in Eolian, but Eo itself need not be aware. Also, I
> > > disagree.
> > > >>
> > > >> Do you mean still use Eo's events to dispatch promises?
> > > >
> > > > Not necessarily, just use the same signature because it's a good one,
> > > > it's extendable, it applies here too, and it's easier for bindings
> this
> > > way.
> > >
> > > It's a good one to who? It's a generic one, for sure, but that doesn't
> > > make it a good one. Promises, for instance, will carry a value, but
> > > it's not immediately available. Even for regular events I don't get
> > > why the object must be fetched from the efl_event...
> > >
> >
> > I'm with Gustavo here, reusing the same callback signature for event
> > and promises don't seems to be a good idea, it just make the usage more
> > confusing and more error prone. Having 2 different signature will make
> > the separation line between events and promises more clear.
> >
>
> I can hear Cedric screaming in despair on the other side of the planet.
>
> We argued that a single signature was better, as our different callback
> signatures (ecore events, evas events. smart callbacks, ...) were one of
> the pain points of using EFL. Now it's pretty clear some people want to
> reintroduce this with promises vs. events. Gustavo missed these heated
> arguments as he started working back on EFL after those long mail threads.
> Same for why object is in Efl_Event rather than being in the argument list.
>

For what I remember we discussed that all EVENTS must use the same
signature, and I'm ok with that. But promises are different, they are not
events.

But I agree with you that we are arguing too much without a clear view of
what
we have now and what we are going to implement wrt promises and future.
At this point I'm also confused between future and promise... I highly
suggest
to write a wiki page with all the needed explanations and examples usage for
both promise and future , so that we can discuss with a documented base.




>
> To be fair, promises were supposed to carry a single value only, IOW
> Efl_Event.info was supposed to be the value. No double cast. Thinking of
> it, I'm not sure why "next" isn't in fact a property on the promise itself
> (as it's Efl_Event.object), rather than being awkwardly passed in the event
> info -- there may be a good reason. (see also efl_event_callback_stop).
>
> Anyway. I'll wait until I can see *exactly* how async operations (image
> file_set in particular) work with promises. Too much arguing about unclear
> details until that is done.
>
> --
> Jean-Philippe André
> 
> --
> ___
> 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] EFL interface, what's left to be done

[Tom Hacohen]

On 22/09/16 00:34, Cedric BAIL wrote:
> On Wed, Sep 21, 2016 at 1:46 AM, Tom Hacohen  wrote:
>> On 19/09/16 23:33, Cedric BAIL wrote:
>>> On Mon, Sep 19, 2016 at 2:48 PM, Tom Hacohen  wrote:
 We haven't agreed on merging Eo, Efl and Ecore. I'm actually pretty much
 against it.
>>>
>>> There was a thread weeks ago. You indeed didn't take part of that
>>> discussion, but everyone else involved in that thread was ok. Actually
>>> the discussion evolved more into a what else to merge in. So their was
>>> an agreement before this email.
>>
>> Sorry, I missed that thread. What was the topic?
>
> Merging eo, efl and ecore. Like in the title :-)

I remember that thread now, I misunderstood what you meant by merging 
when you said it back then, and now with your promise inside lib/eo/ I 
understand what you meant, and I'm very much against it.

Let me clarify what I mean compared to my understanding of what you 
mean. What I mean is what I thought was discussed in that thread.
I'm fine with:
Linking everything into one big fat ugly libefl.so (would rather not, 
but OKish with that).
Having Efl.h that includes Eo.h, Elementary.h and etc.
Having an efl_init() and an efl_shutdown() that call them all.

But if you think about it, it's essentially what we have in elementary. 
It does all of the above except for the one binary linked together. 
Which I'm mostly OK with (although see Marcel's comment about eo_debug 
about which I forgot. Modularity has many advantages).

What I'm *not* OK with:
Creating interdependency between the libraries and essentially making 
libefl.so Ecore 2.0. One place to store everything. Units make a lot of 
sense, of the advantages have been discussed above. My eo_debug trick 
(which is ready, I just need to enable it, again, see marcel's email for 
details) requires this separation.

>
 Eo is clean and hasn't been "polluted" by async, mainloop and etc. That's a
 good thing. This makes our infrastructure easier to test.
>>>
>>> Please define "clean" as it is a bit abstract to me here. What I am
>>> looking for here is the minimal set of component I need to have
>>> something useful. Is Eo useful by itself ? With just Efl.Object ? Sure
>>> you could do C without the C library, but would you ?
>>
>> You are right. Let's merge in Eina too.
>
> That was kind of the discussion. Argument against merging eina, from
> myself, is that we do have a lot of tool, just in tree, that do only
> depends on eina and not on anything else.

I'm also against that btw. If anything, I'm almost OK with merging Eo 
and Eina. Or at least more OK than merging Eo up the stack, but even 
that doesn't make sense to me.

>
>> Or without joking: people have been using Eo without ecore and without
>> Efl.Object. One example is Mike in E (reverted now because Eo was
>> undeclared stable). You'll probably end up using Ecore in the same app,
>> but again, everything you can say here you can say about Eina too.
>
> Do we have any example of an application that use Eo without Ecore or
> Efl today ?

edje_cc, expedite, erigo-cli, clouseau-launcher (not the gui) and etc, 
all depend on Eo and not on graphics. As for Ecore: I'm actually not 
sure, some probably use ecore for networking, but it doesn't matter, 
that's just a convenience that happened to be relevant for this case. 
Sort of: if you can afford to use something that makes your life a bit 
easier, why not.

>
>> By "clean" I mean "isolated" or "untainted by its users up the stack".
>> (see next comment for more info).
>>
>>> I think that your disagreement about merging is only and just because
>>> you do not want to make asynchronous request a core feature of EFL.
>>> The rest is mostly rhetoric. Could you please explain why you have so
>>> much resistance to it being rolled into more place in efl ?
>>
>> That is exactly the reason (was I hiding it?), but not only, and one
>> example of not "clean".
>>
>> A while back I was giving you some flack for not writing tests for a
>> component of the EFL and cited Eo as an example of getting high test
>> coverage. You then laughed it off and said something in the lines of
>> "it's easier to test because it's smaller and not async" or something
>> like that.
>> **THAT IS EXACTLY MY POINT.**
>>  From my experience (and I guess the industry's collective experience),
>> having small separate units make quality assurance easier, units more
>> testable (because you can easily unit test) and the code easier to maintain.
>
> In my opinion there is a lot of code in Eo that is far from nice to
> read and easy to maintain. First example is how intricate our pointer
> infrastructure is in eo and how little it makes sense. I have to go
> back at eina_safepointer, but there is seriously no justification for
> that. Especially when it hasn't help us catch thread safety bugs for
> example. So I agree with your small unit, but small unit has nothing
> todo as per library, it has to do with 

Re: [E-devel] EFL interface, what's left to be done

[Tom Hacohen]

On 22/09/16 07:55, Jean-Philippe André wrote:
> Hi,
>
> On 22 September 2016 at 15:34, Davide Andreoli 
> wrote:
>
>> 2016-09-22 0:45 GMT+02:00 Gustavo Sverzut Barbieri :
>>
>>> On Wed, Sep 21, 2016 at 11:33 AM, Tom Hacohen 
>> wrote:
 On 21/09/16 15:10, Gustavo Sverzut Barbieri wrote:
> On Wed, Sep 21, 2016 at 5:26 AM, Tom Hacohen 
>>> wrote:
> [...]
>>> promise/future should be first-class citizen... as well as iterator
>>> and the likes. There is a start already, but refinement is really
>>> needed, like returning an iterator should handle warn_unused,
>> free,
>>> own... Promise should have its own callback signature, simplified
>> for
>>> the user.
>>>
>>
>> They can, be, but they will just be provided by Eo. There's no need
>> for
>> any special treatment in Eo.
>>
>> Promise signature: you don't need to do it in Eo. I mean, you can
>> add a
>> special type in Eolian, but Eo itself need not be aware. Also, I
>>> disagree.
>
> Do you mean still use Eo's events to dispatch promises?

 Not necessarily, just use the same signature because it's a good one,
 it's extendable, it applies here too, and it's easier for bindings this
>>> way.
>>>
>>> It's a good one to who? It's a generic one, for sure, but that doesn't
>>> make it a good one. Promises, for instance, will carry a value, but
>>> it's not immediately available. Even for regular events I don't get
>>> why the object must be fetched from the efl_event...
>>>
>>
>> I'm with Gustavo here, reusing the same callback signature for event
>> and promises don't seems to be a good idea, it just make the usage more
>> confusing and more error prone. Having 2 different signature will make
>> the separation line between events and promises more clear.
>>
>
> I can hear Cedric screaming in despair on the other side of the planet.
>
> We argued that a single signature was better, as our different callback
> signatures (ecore events, evas events. smart callbacks, ...) were one of
> the pain points of using EFL. Now it's pretty clear some people want to
> reintroduce this with promises vs. events. Gustavo missed these heated
> arguments as he started working back on EFL after those long mail threads.
> Same for why object is in Efl_Event rather than being in the argument list.
>
> To be fair, promises were supposed to carry a single value only, IOW
> Efl_Event.info was supposed to be the value. No double cast. Thinking of
> it, I'm not sure why "next" isn't in fact a property on the promise itself
> (as it's Efl_Event.object), rather than being awkwardly passed in the event
> info -- there may be a good reason. (see also efl_event_callback_stop).
>
> Anyway. I'll wait until I can see *exactly* how async operations (image
> file_set in particular) work with promises. Too much arguing about unclear
> details until that is done.
>

Every word in stone. I'm kind of tired at this point by rearguing 
everything all the time. It has already been discussed to (my) death.

--
Tom.

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EFL interface, what's left to be done

[marcel-hollerbach]

Hello,

On Mon, Sep 19, 2016 at 03:33:50PM -0700, Cedric BAIL wrote:
> On Mon, Sep 19, 2016 at 2:48 PM, Tom Hacohen  wrote:
> > We haven't agreed on merging Eo, Efl and Ecore. I'm actually pretty much
> > against it.
> 
> There was a thread weeks ago. You indeed didn't take part of that
> discussion, but everyone else involved in that thread was ok. Actually
> the discussion evolved more into a what else to merge in. So their was
> an agreement before this email.
> 
> > Eo is clean and hasn't been "polluted" by async, mainloop and etc. That's a
> > good thing. This makes our infrastructure easier to test.
> 
> Please define "clean" as it is a bit abstract to me here. What I am
> looking for here is the minimal set of component I need to have
> something useful. Is Eo useful by itself ? With just Efl.Object ? Sure
> you could do C without the C library, but would you ?
> 
> I think that your disagreement about merging is only and just because
> you do not want to make asynchronous request a core feature of EFL.
> The rest is mostly rhetoric. Could you please explain why you have so
> much resistance to it being rolled into more place in efl ?
> 
> As for the tests, I really don't like our eo tests. They are not
> really testing a clean scenario that is possible to guess, but just a
> mismatch of everything into one big C file. When something break
> there, you can't just rely on the name of the tests, or reading
> quickly the code to guess what's happening. Nop. You have to get
> hundred of lines of tests with little logical connection to each
> other. I have found them less than useful when developping (And some
> times buggy, as instead of testing a scenario that makes sense, they
> were just testing that the code was matching the tests). So I don't
> get your argument of making it easier to tests.
> 
> > If you mean just compile them together, then there's no point in it.
> > I know why you want to do it, you want to do it because you put Efl.Future
> > inside libeo.so, but the correct thing to do is probably not to put it
> > there.
> 
> I don't want to just compile them together. I want to merge there
> headers. Make it just one library. Make efl.object, efl.future and
> efl.loop one core. Obviously because I want to see efl as providing a
> core asynchronous library with defined pattern. One asynchronous
> pattern is "events", which is like an UDP broadcast (default
> behavior)/multicast (with effort) solution. Efl.Future is more the
> equivalent of a TCP connection. I think providing one without the
> other is going to push for a world of broadcast solution which is not
> always the right pattern. Maybe we should remove events support from
> Eo to avoid this problem.

I have two concerns about merging binarys & headers.

First the binarys, for eo there is EO_DEBUG, which just helped me a lot
finding out a issue where events in eo where not emitted. After speaking
with Tom he told me that EO_DEBUG was meant for compiling eo twice, once
with enabled EO_DEBUG (prints out huge errormessages about missing
leaks etc. or unsorted things which are expected to be sorted), and the
other time without EO_DEBUG, now a library could decide which eo-lib to
load, and so give a user a very easy possiblity to debug eo. With
merging those binary you are adding a huge overhead, since enablding
this EO_DEBUG possibility is now also requireing the other things to be
compiled twice, which would add a overhead. So i would just leave out
what currently is eo.

To the headers, from a POV of someone which needs to learn efl (or wants
to). If you have tiny little units defined by a header and its
implementations, you can learn the codebase quite fast, since eo is not
much of code, but very powerfull and basically used everywhere. So IMO
just leave this eo directory as it is, with its baseclass, and the rest,
its easy to understand like that.
Also in the view of abstraction, eo solves the problem of providing a
OOP solution for c, if you are interested in this solution. IMO timers
are not really part of solving that problem, and thus not really
something which should be merged with ecore.
Also, why not just add a efl header, which basically includes all efl
subsystem headers? so the code gets small, and the view of "we are one
library" is given even if the subsystems are still clearly seperated.

Greetings
   bu5hm4n

> > I need to properly review this list for a more complete reply, but I just
> > wanted to trigger this discussion before you go to sleep.
> 
> You mean, before you go to sleep ? I still have half a day to go ! :-)
> 
> Cheers,
>   Cedric
> 
> --
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--

Re: [E-devel] EFL interface, what's left to be done

[Simon Lees]

On 09/22/2016 09:04 AM, Cedric BAIL wrote:
> On Wed, Sep 21, 2016 at 1:46 AM, Tom Hacohen  wrote:
>> On 19/09/16 23:33, Cedric BAIL wrote:
>>> On Mon, Sep 19, 2016 at 2:48 PM, Tom Hacohen  wrote:
 We haven't agreed on merging Eo, Efl and Ecore. I'm actually pretty much
 against it.
>>>
>>> There was a thread weeks ago. You indeed didn't take part of that
>>> discussion, but everyone else involved in that thread was ok. Actually
>>> the discussion evolved more into a what else to merge in. So their was
>>> an agreement before this email.
>>
>> Sorry, I missed that thread. What was the topic?
> 
> Merging eo, efl and ecore. Like in the title :-)
> 
 Eo is clean and hasn't been "polluted" by async, mainloop and etc. That's a
 good thing. This makes our infrastructure easier to test.
>>>
>>> Please define "clean" as it is a bit abstract to me here. What I am
>>> looking for here is the minimal set of component I need to have
>>> something useful. Is Eo useful by itself ? With just Efl.Object ? Sure
>>> you could do C without the C library, but would you ?
>>
>> You are right. Let's merge in Eina too.
> 
> That was kind of the discussion. Argument against merging eina, from
> myself, is that we do have a lot of tool, just in tree, that do only
> depends on eina and not on anything else.
> 
>> Or without joking: people have been using Eo without ecore and without
>> Efl.Object. One example is Mike in E (reverted now because Eo was
>> undeclared stable). You'll probably end up using Ecore in the same app,
>> but again, everything you can say here you can say about Eina too.
> 
> Do we have any example of an application that use Eo without Ecore or
> Efl today ?
> 

At my previous job I looked into writing some applications that just
used eet but thats the only usecase i can think of.

-- 

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
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EFL interface, what's left to be done

[Jean-Philippe André]

Hi,

On 22 September 2016 at 15:34, Davide Andreoli 
wrote:

> 2016-09-22 0:45 GMT+02:00 Gustavo Sverzut Barbieri :
>
> > On Wed, Sep 21, 2016 at 11:33 AM, Tom Hacohen 
> wrote:
> > > On 21/09/16 15:10, Gustavo Sverzut Barbieri wrote:
> > >> On Wed, Sep 21, 2016 at 5:26 AM, Tom Hacohen 
> > wrote:
> > >> [...]
> >  promise/future should be first-class citizen... as well as iterator
> >  and the likes. There is a start already, but refinement is really
> >  needed, like returning an iterator should handle warn_unused,
> free,
> >  own... Promise should have its own callback signature, simplified
> for
> >  the user.
> > 
> > >>>
> > >>> They can, be, but they will just be provided by Eo. There's no need
> for
> > >>> any special treatment in Eo.
> > >>>
> > >>> Promise signature: you don't need to do it in Eo. I mean, you can
> add a
> > >>> special type in Eolian, but Eo itself need not be aware. Also, I
> > disagree.
> > >>
> > >> Do you mean still use Eo's events to dispatch promises?
> > >
> > > Not necessarily, just use the same signature because it's a good one,
> > > it's extendable, it applies here too, and it's easier for bindings this
> > way.
> >
> > It's a good one to who? It's a generic one, for sure, but that doesn't
> > make it a good one. Promises, for instance, will carry a value, but
> > it's not immediately available. Even for regular events I don't get
> > why the object must be fetched from the efl_event...
> >
>
> I'm with Gustavo here, reusing the same callback signature for event
> and promises don't seems to be a good idea, it just make the usage more
> confusing and more error prone. Having 2 different signature will make
> the separation line between events and promises more clear.
>

I can hear Cedric screaming in despair on the other side of the planet.

We argued that a single signature was better, as our different callback
signatures (ecore events, evas events. smart callbacks, ...) were one of
the pain points of using EFL. Now it's pretty clear some people want to
reintroduce this with promises vs. events. Gustavo missed these heated
arguments as he started working back on EFL after those long mail threads.
Same for why object is in Efl_Event rather than being in the argument list.

To be fair, promises were supposed to carry a single value only, IOW
Efl_Event.info was supposed to be the value. No double cast. Thinking of
it, I'm not sure why "next" isn't in fact a property on the promise itself
(as it's Efl_Event.object), rather than being awkwardly passed in the event
info -- there may be a good reason. (see also efl_event_callback_stop).

Anyway. I'll wait until I can see *exactly* how async operations (image
file_set in particular) work with promises. Too much arguing about unclear
details until that is done.

-- 
Jean-Philippe André
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EFL interface, what's left to be done

[Davide Andreoli]

2016-09-22 0:45 GMT+02:00 Gustavo Sverzut Barbieri :

> On Wed, Sep 21, 2016 at 11:33 AM, Tom Hacohen  wrote:
> > On 21/09/16 15:10, Gustavo Sverzut Barbieri wrote:
> >> On Wed, Sep 21, 2016 at 5:26 AM, Tom Hacohen 
> wrote:
> >> [...]
>  promise/future should be first-class citizen... as well as iterator
>  and the likes. There is a start already, but refinement is really
>  needed, like returning an iterator should handle warn_unused, free,
>  own... Promise should have its own callback signature, simplified for
>  the user.
> 
> >>>
> >>> They can, be, but they will just be provided by Eo. There's no need for
> >>> any special treatment in Eo.
> >>>
> >>> Promise signature: you don't need to do it in Eo. I mean, you can add a
> >>> special type in Eolian, but Eo itself need not be aware. Also, I
> disagree.
> >>
> >> Do you mean still use Eo's events to dispatch promises?
> >
> > Not necessarily, just use the same signature because it's a good one,
> > it's extendable, it applies here too, and it's easier for bindings this
> way.
>
> It's a good one to who? It's a generic one, for sure, but that doesn't
> make it a good one. Promises, for instance, will carry a value, but
> it's not immediately available. Even for regular events I don't get
> why the object must be fetched from the efl_event...
>

I'm with Gustavo here, reusing the same callback signature for event
and promises don't seems to be a good idea, it just make the usage more
confusing and more error prone. Having 2 different signature will make
the separation line between events and promises more clear.


>
>
>
> >> I don't get why Efl.Promise is an Eo at all. Looking at the code shows
> >> now hints of benefits. Asking Cedric leads me to an awful answer...
> >> :-/
> >>
> >> The promise thing should only be a thin layer that forces a clear
> >> pattern: wait for data, deliver data or call failure. I don't get why
> >> in the other thread people were talking about references in promises,
> >> inheritance, etc.
> >>
> >
> > Not sure about inheritance, but you need references for lifecycle. It's
> > even better when you have automatic lifecycle control, so when an object
> > dies, the associated promise dies too.
>
> the lifecycle of a promise is simple and there should be no refs on
> it. OTOH, if it's returned by an object, then the object indeed should
> cancel all its promises. But it must know that already, after all it
> must deliver a value sooner or later.
>
> IOW: Eo should know about promises, promises shouldn't know about
> eo... or at least don't need to.
>
>
>
>  AND if possible, make eolian or a new tool to handle connections for
>  us, if it was easy to declare objects with composition of
>  events/promises, it would save us lots of typing and errors.
> 
> 
> >>>
> >>> I'm not sure what you meant here.
> >>
> >> the process of creating and object, setting its properties and
> >> connecting events is painful in C. We need to replicate the whole
> >> "_${METHOD}(efl_added, ${VALUE})"... for events it's even
> >> worse.
> >>
> >> While the API is what it should be, it's PITA to use. If we could
> >> extend the generator to do those for us, we'd have to implement only
> >> high level functions. Like it does for C++ or Lua bindings, do to C
> >> "user code" (could also do C++/Lua user code as well). Example:
> >>
> >> myapp.eou:  # eou = eo user
> >>
> >> objects {
> >> xpto { /* creates an object called "xpto" */
> >>children {
> >>   window { /* window is part of xpto, it will be created using
> >> given type and properties */
> >>  type: Efl.Ui.Win;
> >>  constructor {
> >> type: Efl.Ui.Win.Type.basic;
> >> title: "hello world";
> >>  }
> >>  events { /* these will be connected for you, callback
> >> handlers are expanded based on event payload */
> >> resized @proxy; /* proxy = will forward this event as
> >> "xpto" using the same name */
> >> delete,request; /* user must implement the callback
> >> with handler */
> >>  }
> >>   }
> >>   box {
> >>  type: Efl.Ui.Box;
> >>   }
> >>   label1 {
> >>  type: Efl.Ui.Label;
> >>   }
> >>   label2 {
> >>  type: Efl.Ui.Label;
> >>   }
> >>   entry {
> >>  type: Efl.Ui.Entry;
> >>   }
> >>   }
> >>
> >>connections {
> >>   entry: changed -> label2: text.set; /* somehow like Qt's
> >> signal connection */
> >>}
> >>
> >>composition { /* basic method calls using other objects and
> constants */
> >>box.pack_align(0.5, 0.5);
> >>
> >>label1.hint_align.set(0.0, 0.0);
> >>box.pack(label1);
> >>
> >>label2.hint_align.set(1.0, 1.0);
> >>

Re: [E-devel] EFL interface, what's left to be done

[Cedric BAIL]

On Wed, Sep 21, 2016 at 1:46 AM, Tom Hacohen  wrote:
> On 19/09/16 23:33, Cedric BAIL wrote:
>> On Mon, Sep 19, 2016 at 2:48 PM, Tom Hacohen  wrote:
>>> We haven't agreed on merging Eo, Efl and Ecore. I'm actually pretty much
>>> against it.
>>
>> There was a thread weeks ago. You indeed didn't take part of that
>> discussion, but everyone else involved in that thread was ok. Actually
>> the discussion evolved more into a what else to merge in. So their was
>> an agreement before this email.
>
> Sorry, I missed that thread. What was the topic?

Merging eo, efl and ecore. Like in the title :-)

>>> Eo is clean and hasn't been "polluted" by async, mainloop and etc. That's a
>>> good thing. This makes our infrastructure easier to test.
>>
>> Please define "clean" as it is a bit abstract to me here. What I am
>> looking for here is the minimal set of component I need to have
>> something useful. Is Eo useful by itself ? With just Efl.Object ? Sure
>> you could do C without the C library, but would you ?
>
> You are right. Let's merge in Eina too.

That was kind of the discussion. Argument against merging eina, from
myself, is that we do have a lot of tool, just in tree, that do only
depends on eina and not on anything else.

> Or without joking: people have been using Eo without ecore and without
> Efl.Object. One example is Mike in E (reverted now because Eo was
> undeclared stable). You'll probably end up using Ecore in the same app,
> but again, everything you can say here you can say about Eina too.

Do we have any example of an application that use Eo without Ecore or
Efl today ?

> By "clean" I mean "isolated" or "untainted by its users up the stack".
> (see next comment for more info).
>
>> I think that your disagreement about merging is only and just because
>> you do not want to make asynchronous request a core feature of EFL.
>> The rest is mostly rhetoric. Could you please explain why you have so
>> much resistance to it being rolled into more place in efl ?
>
> That is exactly the reason (was I hiding it?), but not only, and one
> example of not "clean".
>
> A while back I was giving you some flack for not writing tests for a
> component of the EFL and cited Eo as an example of getting high test
> coverage. You then laughed it off and said something in the lines of
> "it's easier to test because it's smaller and not async" or something
> like that.
> **THAT IS EXACTLY MY POINT.**
>  From my experience (and I guess the industry's collective experience),
> having small separate units make quality assurance easier, units more
> testable (because you can easily unit test) and the code easier to maintain.

In my opinion there is a lot of code in Eo that is far from nice to
read and easy to maintain. First example is how intricate our pointer
infrastructure is in eo and how little it makes sense. I have to go
back at eina_safepointer, but there is seriously no justification for
that. Especially when it hasn't help us catch thread safety bugs for
example. So I agree with your small unit, but small unit has nothing
todo as per library, it has to do with how we divide things between
functions and files.

>> As for the tests, I really don't like our eo tests. They are not
>> really testing a clean scenario that is possible to guess, but just a
>> mismatch of everything into one big C file. When something break
>> there, you can't just rely on the name of the tests, or reading
>> quickly the code to guess what's happening. Nop. You have to get
>> hundred of lines of tests with little logical connection to each
>> other. I have found them less than useful when developping (And some
>> times buggy, as instead of testing a scenario that makes sense, they
>> were just testing that the code was matching the tests). So I don't
>> get your argument of making it easier to tests.
>
> The Eo suite is a mixture of success-scenario, failure-scenario and
> regression testing.
> Success scenario: making sure an expected scenario works.
> Failure scenario: making sure an expected scenario fails.
> regression testing: making sure what we have stays the same.
>
> Success scenarios would rarely need changing, only if you change
> something drastic or make the code more strict. Failure would need to
> change a bit more often, depending on how strict we make the code.
> Regression testing will probably change often, as they are there so you
> *understand* that you are changing behaviour, even if undocumented.
>
> I'm not aware of any buggy tests, but do let me know if you find one,
> and while at it, if possible, try and fix them.

The tests for hot event was completely backward and wrong. Don't worry
when I find a bugs I fix it.

> You have to also remember, these tests have been with us through a few
> Eo rewrites. They have been here from day 1. :)

They would benefit from some cleanup for sure and to be closer to an unit tests.

>>> If you mean just compile them together, then there's 

Re: [E-devel] EFL interface, what's left to be done

[Gustavo Sverzut Barbieri]

On Wed, Sep 21, 2016 at 11:33 AM, Tom Hacohen  wrote:
> On 21/09/16 15:10, Gustavo Sverzut Barbieri wrote:
>> On Wed, Sep 21, 2016 at 5:26 AM, Tom Hacohen  wrote:
>> [...]
 promise/future should be first-class citizen... as well as iterator
 and the likes. There is a start already, but refinement is really
 needed, like returning an iterator should handle warn_unused, free,
 own... Promise should have its own callback signature, simplified for
 the user.

>>>
>>> They can, be, but they will just be provided by Eo. There's no need for
>>> any special treatment in Eo.
>>>
>>> Promise signature: you don't need to do it in Eo. I mean, you can add a
>>> special type in Eolian, but Eo itself need not be aware. Also, I disagree.
>>
>> Do you mean still use Eo's events to dispatch promises?
>
> Not necessarily, just use the same signature because it's a good one,
> it's extendable, it applies here too, and it's easier for bindings this way.

It's a good one to who? It's a generic one, for sure, but that doesn't
make it a good one. Promises, for instance, will carry a value, but
it's not immediately available. Even for regular events I don't get
why the object must be fetched from the efl_event...



>> I don't get why Efl.Promise is an Eo at all. Looking at the code shows
>> now hints of benefits. Asking Cedric leads me to an awful answer...
>> :-/
>>
>> The promise thing should only be a thin layer that forces a clear
>> pattern: wait for data, deliver data or call failure. I don't get why
>> in the other thread people were talking about references in promises,
>> inheritance, etc.
>>
>
> Not sure about inheritance, but you need references for lifecycle. It's
> even better when you have automatic lifecycle control, so when an object
> dies, the associated promise dies too.

the lifecycle of a promise is simple and there should be no refs on
it. OTOH, if it's returned by an object, then the object indeed should
cancel all its promises. But it must know that already, after all it
must deliver a value sooner or later.

IOW: Eo should know about promises, promises shouldn't know about
eo... or at least don't need to.



 AND if possible, make eolian or a new tool to handle connections for
 us, if it was easy to declare objects with composition of
 events/promises, it would save us lots of typing and errors.


>>>
>>> I'm not sure what you meant here.
>>
>> the process of creating and object, setting its properties and
>> connecting events is painful in C. We need to replicate the whole
>> "_${METHOD}(efl_added, ${VALUE})"... for events it's even
>> worse.
>>
>> While the API is what it should be, it's PITA to use. If we could
>> extend the generator to do those for us, we'd have to implement only
>> high level functions. Like it does for C++ or Lua bindings, do to C
>> "user code" (could also do C++/Lua user code as well). Example:
>>
>> myapp.eou:  # eou = eo user
>>
>> objects {
>> xpto { /* creates an object called "xpto" */
>>children {
>>   window { /* window is part of xpto, it will be created using
>> given type and properties */
>>  type: Efl.Ui.Win;
>>  constructor {
>> type: Efl.Ui.Win.Type.basic;
>> title: "hello world";
>>  }
>>  events { /* these will be connected for you, callback
>> handlers are expanded based on event payload */
>> resized @proxy; /* proxy = will forward this event as
>> "xpto" using the same name */
>> delete,request; /* user must implement the callback
>> with handler */
>>  }
>>   }
>>   box {
>>  type: Efl.Ui.Box;
>>   }
>>   label1 {
>>  type: Efl.Ui.Label;
>>   }
>>   label2 {
>>  type: Efl.Ui.Label;
>>   }
>>   entry {
>>  type: Efl.Ui.Entry;
>>   }
>>   }
>>
>>connections {
>>   entry: changed -> label2: text.set; /* somehow like Qt's
>> signal connection */
>>}
>>
>>composition { /* basic method calls using other objects and constants 
>> */
>>box.pack_align(0.5, 0.5);
>>
>>label1.hint_align.set(0.0, 0.0);
>>box.pack(label1);
>>
>>label2.hint_align.set(1.0, 1.0);
>>box.pack(label2);
>>box.pack(entry);
>>  }
>> }
>> }
>>
>>
>> Then in my code I'd just:
>>
>> #include "myapp.eou.h"
>>
>> static void _xpto_window_delete_request(Eo *xpto, Eo *window) /*
>> nothing else as there is no payload in that event */
>> {
>> printf("window was closed\n");
>> }
>>
>> static void _xpto_resized(void *data, const Efl_Event *event) // or we
>> create an xpto_event_resized_add() which unpacks and makes it easier
>> to use
>> {
>> }
>>
>> int main() {
>>  // ...
>>
>>  Eo *xpto = xpto_new();
>>  

Re: [E-devel] EFL interface, what's left to be done

[Cedric BAIL]

Hi JP,

On Tue, Sep 20, 2016 at 11:52 PM, Jean-Philippe André  wrote:
> On 20 September 2016 at 06:05, Cedric BAIL  wrote:
>> So this email is going over what is left to be done to call EFL
>> interface done. Most of this require still discussion also. Here it
>> goes :
>>
>> - Merge Eo, Efl and Ecore
>> - Make efl_uri_set/efl_file_set asynchronous
>> - Convert Ecore_Exe to the new efl_io API
>> - Fixup efl/interface/*.eo to all be in the correct namespace
>> - Disable installation of evas/canvas/evas*.eo
>> - Convert edje to become efl_canvas_layout
>> - Update Edje with the new Text API
>> - Convert elm_layout to become efl_ui_layout
>> - Convert elm_widget to be an efl_ui_object of some sort
>> - Update all efl data model to use efl_future/efl_promise
>> - Add proper View and Controller for Genlist/Gengrid (see D3952 for some
>> ideas)
>> - There is still a large amount of .eo in elementary that are in elm
>> namespace. This shouldn't be installed nor appear anywhere in the
>> hierarchy.
>> - Finish porting some of the widget to Efl.Ui namespace (photocam,
>> index, entry, button, calendar, clock, menu, ...). This needs to be
>> clarified with some pending patch in phab.
>>
>> This are quite a large todo list to be done with, hopefully it will...
>>
>
> - evas smart objects
> Evas smart objects are a stable legacy API but their equivalent in EO is
> horrible. Efl.Canvas.Group is not an acceptable replacement in its current
> form. All the methods this class defines are poorly defined overrides over
> the basic object functions (show, hide, etc...). I've started some work in
> this direction but it's tedious and risky. The alternative is to have no
> API for custom smart objects.
>
> - elm_widget
> elm widget was and still is an unstable / private API. I don't think
> cleaning up this API is in the scope of our interfaces work, right now.

I kind of forgot about smart object and not really. Well, I was
wondering if we could make elm_widget the exposed way of doing smart
object with efl interface. I guess it would be indeed to big of a
scope. I am fine with focusing on a simpler evas level smart object.
The problem is that elm_widget is in the hierarchy of every elementary
widget. So at least some binding may expose it in some way. We need a
way to hide/reduce the visibility of that API at least.

> - text part API
> Textblock now has a new shiny eo api but edje_object and elm_layout still
> define _part_text_ APIs. This needs to be transformed to Efl.Part.

Yup, that was my point regarding updating edje and elm entry to use
the new text API. A huge work and I have no idea of its current
status.

> - efl.ui.window + elm_conformant
> Ideally window should have merged in the features of conformant so we avoid
> this extra awkward widget. Window was supposed to handle what conformant
> does. The reality is that no work towards that goal has been done yet.

Oh, I missed that bit. Hum, that's problematic indeed. Need to be done.

Thanks,
-- 
Cedric BAIL

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EFL interface, what's left to be done

[Tom Hacohen]

On 21/09/16 15:10, Gustavo Sverzut Barbieri wrote:
> On Wed, Sep 21, 2016 at 5:26 AM, Tom Hacohen  wrote:
> [...]
>>> promise/future should be first-class citizen... as well as iterator
>>> and the likes. There is a start already, but refinement is really
>>> needed, like returning an iterator should handle warn_unused, free,
>>> own... Promise should have its own callback signature, simplified for
>>> the user.
>>>
>>
>> They can, be, but they will just be provided by Eo. There's no need for
>> any special treatment in Eo.
>>
>> Promise signature: you don't need to do it in Eo. I mean, you can add a
>> special type in Eolian, but Eo itself need not be aware. Also, I disagree.
>
> Do you mean still use Eo's events to dispatch promises?

Not necessarily, just use the same signature because it's a good one, 
it's extendable, it applies here too, and it's easier for bindings this way.

>
> I don't get why Efl.Promise is an Eo at all. Looking at the code shows
> now hints of benefits. Asking Cedric leads me to an awful answer...
> :-/
>
> The promise thing should only be a thin layer that forces a clear
> pattern: wait for data, deliver data or call failure. I don't get why
> in the other thread people were talking about references in promises,
> inheritance, etc.
>

Not sure about inheritance, but you need references for lifecycle. It's 
even better when you have automatic lifecycle control, so when an object 
dies, the associated promise dies too.

>
>>> AND if possible, make eolian or a new tool to handle connections for
>>> us, if it was easy to declare objects with composition of
>>> events/promises, it would save us lots of typing and errors.
>>>
>>>
>>
>> I'm not sure what you meant here.
>
> the process of creating and object, setting its properties and
> connecting events is painful in C. We need to replicate the whole
> "_${METHOD}(efl_added, ${VALUE})"... for events it's even
> worse.
>
> While the API is what it should be, it's PITA to use. If we could
> extend the generator to do those for us, we'd have to implement only
> high level functions. Like it does for C++ or Lua bindings, do to C
> "user code" (could also do C++/Lua user code as well). Example:
>
> myapp.eou:  # eou = eo user
>
> objects {
> xpto { /* creates an object called "xpto" */
>children {
>   window { /* window is part of xpto, it will be created using
> given type and properties */
>  type: Efl.Ui.Win;
>  constructor {
> type: Efl.Ui.Win.Type.basic;
> title: "hello world";
>  }
>  events { /* these will be connected for you, callback
> handlers are expanded based on event payload */
> resized @proxy; /* proxy = will forward this event as
> "xpto" using the same name */
> delete,request; /* user must implement the callback
> with handler */
>  }
>   }
>   box {
>  type: Efl.Ui.Box;
>   }
>   label1 {
>  type: Efl.Ui.Label;
>   }
>   label2 {
>  type: Efl.Ui.Label;
>   }
>   entry {
>  type: Efl.Ui.Entry;
>   }
>   }
>
>connections {
>   entry: changed -> label2: text.set; /* somehow like Qt's
> signal connection */
>}
>
>composition { /* basic method calls using other objects and constants 
> */
>box.pack_align(0.5, 0.5);
>
>label1.hint_align.set(0.0, 0.0);
>box.pack(label1);
>
>label2.hint_align.set(1.0, 1.0);
>box.pack(label2);
>box.pack(entry);
>  }
> }
> }
>
>
> Then in my code I'd just:
>
> #include "myapp.eou.h"
>
> static void _xpto_window_delete_request(Eo *xpto, Eo *window) /*
> nothing else as there is no payload in that event */
> {
> printf("window was closed\n");
> }
>
> static void _xpto_resized(void *data, const Efl_Event *event) // or we
> create an xpto_event_resized_add() which unpacks and makes it easier
> to use
> {
> }
>
> int main() {
>  // ...
>
>  Eo *xpto = xpto_new();
>  efl_event_callback_add(xpto, XPTO_EVENT_RESIZED, _xpto_resized, NULL);
>
>   // ...
> }
>
> #include "myapp.eou.c"
>


If I understand you correctly, you want a UI description language. Yes, 
we have that in the words under the "erigo" project. Erigo is the gui 
builder but it also implement a UI descrption language and should 
include cli tools that do just that. We already speced the language, 
though unfortunately the author is currently unavailable, so work stopped.

--
Tom.

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EFL interface, what's left to be done

[Gustavo Sverzut Barbieri]

On Wed, Sep 21, 2016 at 5:26 AM, Tom Hacohen  wrote:
[...]
>> promise/future should be first-class citizen... as well as iterator
>> and the likes. There is a start already, but refinement is really
>> needed, like returning an iterator should handle warn_unused, free,
>> own... Promise should have its own callback signature, simplified for
>> the user.
>>
>
> They can, be, but they will just be provided by Eo. There's no need for
> any special treatment in Eo.
>
> Promise signature: you don't need to do it in Eo. I mean, you can add a
> special type in Eolian, but Eo itself need not be aware. Also, I disagree.

Do you mean still use Eo's events to dispatch promises?

I don't get why Efl.Promise is an Eo at all. Looking at the code shows
now hints of benefits. Asking Cedric leads me to an awful answer...
:-/

The promise thing should only be a thin layer that forces a clear
pattern: wait for data, deliver data or call failure. I don't get why
in the other thread people were talking about references in promises,
inheritance, etc.


>> AND if possible, make eolian or a new tool to handle connections for
>> us, if it was easy to declare objects with composition of
>> events/promises, it would save us lots of typing and errors.
>>
>>
>
> I'm not sure what you meant here.

the process of creating and object, setting its properties and
connecting events is painful in C. We need to replicate the whole
"_${METHOD}(efl_added, ${VALUE})"... for events it's even
worse.

While the API is what it should be, it's PITA to use. If we could
extend the generator to do those for us, we'd have to implement only
high level functions. Like it does for C++ or Lua bindings, do to C
"user code" (could also do C++/Lua user code as well). Example:

myapp.eou:  # eou = eo user

objects {
xpto { /* creates an object called "xpto" */
   children {
  window { /* window is part of xpto, it will be created using
given type and properties */
 type: Efl.Ui.Win;
 constructor {
type: Efl.Ui.Win.Type.basic;
title: "hello world";
 }
 events { /* these will be connected for you, callback
handlers are expanded based on event payload */
resized @proxy; /* proxy = will forward this event as
"xpto" using the same name */
delete,request; /* user must implement the callback
with handler */
 }
  }
  box {
 type: Efl.Ui.Box;
  }
  label1 {
 type: Efl.Ui.Label;
  }
  label2 {
 type: Efl.Ui.Label;
  }
  entry {
 type: Efl.Ui.Entry;
  }
  }

   connections {
  entry: changed -> label2: text.set; /* somehow like Qt's
signal connection */
   }

   composition { /* basic method calls using other objects and constants */
   box.pack_align(0.5, 0.5);

   label1.hint_align.set(0.0, 0.0);
   box.pack(label1);

   label2.hint_align.set(1.0, 1.0);
   box.pack(label2);
   box.pack(entry);
 }
}
}


Then in my code I'd just:

#include "myapp.eou.h"

static void _xpto_window_delete_request(Eo *xpto, Eo *window) /*
nothing else as there is no payload in that event */
{
printf("window was closed\n");
}

static void _xpto_resized(void *data, const Efl_Event *event) // or we
create an xpto_event_resized_add() which unpacks and makes it easier
to use
{
}

int main() {
 // ...

 Eo *xpto = xpto_new();
 efl_event_callback_add(xpto, XPTO_EVENT_RESIZED, _xpto_resized, NULL);

  // ...
}

#include "myapp.eou.c"



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

Re: [E-devel] EFL interface, what's left to be done

[Tom Hacohen]

On 19/09/16 23:33, Cedric BAIL wrote:
> On Mon, Sep 19, 2016 at 2:48 PM, Tom Hacohen  wrote:
>> We haven't agreed on merging Eo, Efl and Ecore. I'm actually pretty much
>> against it.
>
> There was a thread weeks ago. You indeed didn't take part of that
> discussion, but everyone else involved in that thread was ok. Actually
> the discussion evolved more into a what else to merge in. So their was
> an agreement before this email.

Sorry, I missed that thread. What was the topic?

>
>> Eo is clean and hasn't been "polluted" by async, mainloop and etc. That's a
>> good thing. This makes our infrastructure easier to test.
>
> Please define "clean" as it is a bit abstract to me here. What I am
> looking for here is the minimal set of component I need to have
> something useful. Is Eo useful by itself ? With just Efl.Object ? Sure
> you could do C without the C library, but would you ?

You are right. Let's merge in Eina too.

Or without joking: people have been using Eo without ecore and without 
Efl.Object. One example is Mike in E (reverted now because Eo was 
undeclared stable). You'll probably end up using Ecore in the same app, 
but again, everything you can say here you can say about Eina too.

By "clean" I mean "isolated" or "untainted by its users up the stack". 
(see next comment for more info).

>
> I think that your disagreement about merging is only and just because
> you do not want to make asynchronous request a core feature of EFL.
> The rest is mostly rhetoric. Could you please explain why you have so
> much resistance to it being rolled into more place in efl ?

That is exactly the reason (was I hiding it?), but not only, and one 
example of not "clean".

A while back I was giving you some flack for not writing tests for a 
component of the EFL and cited Eo as an example of getting high test 
coverage. You then laughed it off and said something in the lines of 
"it's easier to test because it's smaller and not async" or something 
like that.
**THAT IS EXACTLY MY POINT.**
 From my experience (and I guess the industry's collective experience), 
having small separate units make quality assurance easier, units more 
testable (because you can easily unit test) and the code easier to maintain.

>
> As for the tests, I really don't like our eo tests. They are not
> really testing a clean scenario that is possible to guess, but just a
> mismatch of everything into one big C file. When something break
> there, you can't just rely on the name of the tests, or reading
> quickly the code to guess what's happening. Nop. You have to get
> hundred of lines of tests with little logical connection to each
> other. I have found them less than useful when developping (And some
> times buggy, as instead of testing a scenario that makes sense, they
> were just testing that the code was matching the tests). So I don't
> get your argument of making it easier to tests.

The Eo suite is a mixture of success-scenario, failure-scenario and 
regression testing.
Success scenario: making sure an expected scenario works.
Failure scenario: making sure an expected scenario fails.
regression testing: making sure what we have stays the same.

Success scenarios would rarely need changing, only if you change 
something drastic or make the code more strict. Failure would need to 
change a bit more often, depending on how strict we make the code. 
Regression testing will probably change often, as they are there so you 
*understand* that you are changing behaviour, even if undocumented.

I'm not aware of any buggy tests, but do let me know if you find one, 
and while at it, if possible, try and fix them.

You have to also remember, these tests have been with us through a few 
Eo rewrites. They have been here from day 1. :)

>
>> If you mean just compile them together, then there's no point in it.
>> I know why you want to do it, you want to do it because you put Efl.Future
>> inside libeo.so, but the correct thing to do is probably not to put it
>> there.
>
> I don't want to just compile them together. I want to merge there
> headers. Make it just one library. Make efl.object, efl.future and
> efl.loop one core. Obviously because I want to see efl as providing a
> core asynchronous library with defined pattern. One asynchronous
> pattern is "events", which is like an UDP broadcast (default
> behavior)/multicast (with effort) solution. Efl.Future is more the
> equivalent of a TCP connection. I think providing one without the
> other is going to push for a world of broadcast solution which is not
> always the right pattern. Maybe we should remove events support from
> Eo to avoid this problem.

Of course also merging the headers. What I meant is: you want a cycle 
dep. Mutual reliance.

It's not really a broadcast, because you need to register to listen.

Removing events from Eo is not the way to go. If you want an async 
pattern, do it up the stack (even eolian) and encourage it there. People 
who use the loop will 

Re: [E-devel] EFL interface, what's left to be done

[Tom Hacohen]

On 20/09/16 05:14, Gustavo Sverzut Barbieri wrote:
> On Mon, Sep 19, 2016 at 7:33 PM, Cedric BAIL  wrote:
>> On Mon, Sep 19, 2016 at 2:48 PM, Tom Hacohen  wrote:
>>> We haven't agreed on merging Eo, Efl and Ecore. I'm actually pretty much
>>> against it.
>>
>> There was a thread weeks ago. You indeed didn't take part of that
>> discussion, but everyone else involved in that thread was ok. Actually
>> the discussion evolved more into a what else to merge in. So their was
>> an agreement before this email.
>>
>>> Eo is clean and hasn't been "polluted" by async, mainloop and etc. That's a
>>> good thing. This makes our infrastructure easier to test.
>>
>> Please define "clean" as it is a bit abstract to me here. What I am
>> looking for here is the minimal set of component I need to have
>> something useful. Is Eo useful by itself ? With just Efl.Object ? Sure
>> you could do C without the C library, but would you ?
>>
>> I think that your disagreement about merging is only and just because
>> you do not want to make asynchronous request a core feature of EFL.
>> The rest is mostly rhetoric. Could you please explain why you have so
>> much resistance to it being rolled into more place in efl ?
>
> [...]
>
>> I don't want to just compile them together. I want to merge there
>> headers. Make it just one library. Make efl.object, efl.future and
>> efl.loop one core. Obviously because I want to see efl as providing a
>> core asynchronous library with defined pattern. One asynchronous
>> pattern is "events", which is like an UDP broadcast (default
>> behavior)/multicast (with effort) solution. Efl.Future is more the
>> equivalent of a TCP connection. I think providing one without the
>> other is going to push for a world of broadcast solution which is not
>> always the right pattern. Maybe we should remove events support from
>> Eo to avoid this problem.
>
> +1 fully agree with Cedric's rationale. Eo's purpose should be
> solely to serve Efl's use cases, which means asynchronous event driven
> programming.

I'll reply to cedric in a moment, but in the meanwhile:

>
> promise/future should be first-class citizen... as well as iterator
> and the likes. There is a start already, but refinement is really
> needed, like returning an iterator should handle warn_unused, free,
> own... Promise should have its own callback signature, simplified for
> the user.
>

They can, be, but they will just be provided by Eo. There's no need for 
any special treatment in Eo.

Promise signature: you don't need to do it in Eo. I mean, you can add a 
special type in Eolian, but Eo itself need not be aware. Also, I disagree.

> AND if possible, make eolian or a new tool to handle connections for
> us, if it was easy to declare objects with composition of
> events/promises, it would save us lots of typing and errors.
>
>

I'm not sure what you meant here.

--
Tom

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EFL interface, what's left to be done

[Jean-Philippe André]

Hi Cedric,

On 20 September 2016 at 06:05, Cedric BAIL  wrote:

> Hello everyone,
>
> So this email is going over what is left to be done to call EFL
> interface done. Most of this require still discussion also. Here it
> goes :
>
> - Merge Eo, Efl and Ecore
> - Make efl_uri_set/efl_file_set asynchronous
> - Convert Ecore_Exe to the new efl_io API
> - Fixup efl/interface/*.eo to all be in the correct namespace
> - Disable installation of evas/canvas/evas*.eo
> - Convert edje to become efl_canvas_layout
> - Update Edje with the new Text API
> - Convert elm_layout to become efl_ui_layout
> - Convert elm_widget to be an efl_ui_object of some sort
> - Update all efl data model to use efl_future/efl_promise
> - Add proper View and Controller for Genlist/Gengrid (see D3952 for some
> ideas)
> - There is still a large amount of .eo in elementary that are in elm
> namespace. This shouldn't be installed nor appear anywhere in the
> hierarchy.
> - Finish porting some of the widget to Efl.Ui namespace (photocam,
> index, entry, button, calendar, clock, menu, ...). This needs to be
> clarified with some pending patch in phab.
>
> This are quite a large todo list to be done with, hopefully it will...
>

- evas smart objects
Evas smart objects are a stable legacy API but their equivalent in EO is
horrible. Efl.Canvas.Group is not an acceptable replacement in its current
form. All the methods this class defines are poorly defined overrides over
the basic object functions (show, hide, etc...). I've started some work in
this direction but it's tedious and risky. The alternative is to have no
API for custom smart objects.

- elm_widget
elm widget was and still is an unstable / private API. I don't think
cleaning up this API is in the scope of our interfaces work, right now.

- text part API
Textblock now has a new shiny eo api but edje_object and elm_layout still
define _part_text_ APIs. This needs to be transformed to Efl.Part.

- efl.ui.window + elm_conformant
Ideally window should have merged in the features of conformant so we avoid
this extra awkward widget. Window was supposed to handle what conformant
does. The reality is that no work towards that goal has been done yet.

-- 
Jean-Philippe André
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EFL interface, what's left to be done

[Gustavo Sverzut Barbieri]

On Mon, Sep 19, 2016 at 7:33 PM, Cedric BAIL  wrote:
> On Mon, Sep 19, 2016 at 2:48 PM, Tom Hacohen  wrote:
>> We haven't agreed on merging Eo, Efl and Ecore. I'm actually pretty much
>> against it.
>
> There was a thread weeks ago. You indeed didn't take part of that
> discussion, but everyone else involved in that thread was ok. Actually
> the discussion evolved more into a what else to merge in. So their was
> an agreement before this email.
>
>> Eo is clean and hasn't been "polluted" by async, mainloop and etc. That's a
>> good thing. This makes our infrastructure easier to test.
>
> Please define "clean" as it is a bit abstract to me here. What I am
> looking for here is the minimal set of component I need to have
> something useful. Is Eo useful by itself ? With just Efl.Object ? Sure
> you could do C without the C library, but would you ?
>
> I think that your disagreement about merging is only and just because
> you do not want to make asynchronous request a core feature of EFL.
> The rest is mostly rhetoric. Could you please explain why you have so
> much resistance to it being rolled into more place in efl ?

[...]

> I don't want to just compile them together. I want to merge there
> headers. Make it just one library. Make efl.object, efl.future and
> efl.loop one core. Obviously because I want to see efl as providing a
> core asynchronous library with defined pattern. One asynchronous
> pattern is "events", which is like an UDP broadcast (default
> behavior)/multicast (with effort) solution. Efl.Future is more the
> equivalent of a TCP connection. I think providing one without the
> other is going to push for a world of broadcast solution which is not
> always the right pattern. Maybe we should remove events support from
> Eo to avoid this problem.

+1 fully agree with Cedric's rationale. Eo's purpose should be
solely to serve Efl's use cases, which means asynchronous event driven
programming.

promise/future should be first-class citizen... as well as iterator
and the likes. There is a start already, but refinement is really
needed, like returning an iterator should handle warn_unused, free,
own... Promise should have its own callback signature, simplified for
the user.

AND if possible, make eolian or a new tool to handle connections for
us, if it was easy to declare objects with composition of
events/promises, it would save us lots of typing and errors.


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

Re: [E-devel] EFL interface, what's left to be done

[Cedric BAIL]

On Mon, Sep 19, 2016 at 2:48 PM, Tom Hacohen  wrote:
> We haven't agreed on merging Eo, Efl and Ecore. I'm actually pretty much
> against it.

There was a thread weeks ago. You indeed didn't take part of that
discussion, but everyone else involved in that thread was ok. Actually
the discussion evolved more into a what else to merge in. So their was
an agreement before this email.

> Eo is clean and hasn't been "polluted" by async, mainloop and etc. That's a
> good thing. This makes our infrastructure easier to test.

Please define "clean" as it is a bit abstract to me here. What I am
looking for here is the minimal set of component I need to have
something useful. Is Eo useful by itself ? With just Efl.Object ? Sure
you could do C without the C library, but would you ?

I think that your disagreement about merging is only and just because
you do not want to make asynchronous request a core feature of EFL.
The rest is mostly rhetoric. Could you please explain why you have so
much resistance to it being rolled into more place in efl ?

As for the tests, I really don't like our eo tests. They are not
really testing a clean scenario that is possible to guess, but just a
mismatch of everything into one big C file. When something break
there, you can't just rely on the name of the tests, or reading
quickly the code to guess what's happening. Nop. You have to get
hundred of lines of tests with little logical connection to each
other. I have found them less than useful when developping (And some
times buggy, as instead of testing a scenario that makes sense, they
were just testing that the code was matching the tests). So I don't
get your argument of making it easier to tests.

> If you mean just compile them together, then there's no point in it.
> I know why you want to do it, you want to do it because you put Efl.Future
> inside libeo.so, but the correct thing to do is probably not to put it
> there.

I don't want to just compile them together. I want to merge there
headers. Make it just one library. Make efl.object, efl.future and
efl.loop one core. Obviously because I want to see efl as providing a
core asynchronous library with defined pattern. One asynchronous
pattern is "events", which is like an UDP broadcast (default
behavior)/multicast (with effort) solution. Efl.Future is more the
equivalent of a TCP connection. I think providing one without the
other is going to push for a world of broadcast solution which is not
always the right pattern. Maybe we should remove events support from
Eo to avoid this problem.

> I need to properly review this list for a more complete reply, but I just
> wanted to trigger this discussion before you go to sleep.

You mean, before you go to sleep ? I still have half a day to go ! :-)

Cheers,
  Cedric

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EFL interface, what's left to be done

[Tom Hacohen]

We haven't agreed on merging Eo, Efl and Ecore. I'm actually pretty much
against it.
Eo is clean and hasn't been "polluted" by async, mainloop and etc. That's a
good thing. This makes our infrastructure easier to test.
If you mean just compile them together, then there's no point in it.
I know why you want to do it, you want to do it because you put Efl.Future
inside libeo.so, but the correct thing to do is probably not to put it
there.

I need to properly review this list for a more complete reply, but I just
wanted to trigger this discussion before you go to sleep.

--
Tom.

On Mon, Sep 19, 2016 at 10:05 PM, Cedric BAIL  wrote:

> Hello everyone,
>
> So this email is going over what is left to be done to call EFL
> interface done. Most of this require still discussion also. Here it
> goes :
>
> - Merge Eo, Efl and Ecore
> - Make efl_uri_set/efl_file_set asynchronous
> - Convert Ecore_Exe to the new efl_io API
> - Fixup efl/interface/*.eo to all be in the correct namespace
> - Disable installation of evas/canvas/evas*.eo
> - Convert edje to become efl_canvas_layout
> - Update Edje with the new Text API
> - Convert elm_layout to become efl_ui_layout
> - Convert elm_widget to be an efl_ui_object of some sort
> - Update all efl data model to use efl_future/efl_promise
> - Add proper View and Controller for Genlist/Gengrid (see D3952 for some
> ideas)
> - There is still a large amount of .eo in elementary that are in elm
> namespace. This shouldn't be installed nor appear anywhere in the
> hierarchy.
> - Finish porting some of the widget to Efl.Ui namespace (photocam,
> index, entry, button, calendar, clock, menu, ...). This needs to be
> clarified with some pending patch in phab.
>
> This are quite a large todo list to be done with, hopefully it will...
> --
> Cedric BAIL
>
> 
> --
> ___
> 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] EFL interface, what's left to be done

[Andrew Williams]

Hi Cedric,

Great list thanks :)

Along with all the breaking changes I thought I would throw a suggestion
into the mix...
How about we move non-core Elementary widgets out to an elm_extra library
not in main efl? There is so much in there that we are struggling to add
important stuff like tabs etc. If we could maintain a little less as a core
group this might be the time?
Also new widgets could start here rather than in efl...

Cheers,
Andy
On Mon, 19 Sep 2016 at 22:06, Cedric BAIL  wrote:

> Hello everyone,
>
> So this email is going over what is left to be done to call EFL
> interface done. Most of this require still discussion also. Here it
> goes :
>
> - Merge Eo, Efl and Ecore
> - Make efl_uri_set/efl_file_set asynchronous
> - Convert Ecore_Exe to the new efl_io API
> - Fixup efl/interface/*.eo to all be in the correct namespace
> - Disable installation of evas/canvas/evas*.eo
> - Convert edje to become efl_canvas_layout
> - Update Edje with the new Text API
> - Convert elm_layout to become efl_ui_layout
> - Convert elm_widget to be an efl_ui_object of some sort
> - Update all efl data model to use efl_future/efl_promise
> - Add proper View and Controller for Genlist/Gengrid (see D3952 for some
> ideas)
> - There is still a large amount of .eo in elementary that are in elm
> namespace. This shouldn't be installed nor appear anywhere in the
> hierarchy.
> - Finish porting some of the widget to Efl.Ui namespace (photocam,
> index, entry, button, calendar, clock, menu, ...). This needs to be
> clarified with some pending patch in phab.
>
> This are quite a large todo list to be done with, hopefully it will...
> --
> Cedric BAIL
>
>
> --
> ___
> 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

[E-devel] EFL interface, what's left to be done

[Cedric BAIL]

Hello everyone,

So this email is going over what is left to be done to call EFL
interface done. Most of this require still discussion also. Here it
goes :

- Merge Eo, Efl and Ecore
- Make efl_uri_set/efl_file_set asynchronous
- Convert Ecore_Exe to the new efl_io API
- Fixup efl/interface/*.eo to all be in the correct namespace
- Disable installation of evas/canvas/evas*.eo
- Convert edje to become efl_canvas_layout
- Update Edje with the new Text API
- Convert elm_layout to become efl_ui_layout
- Convert elm_widget to be an efl_ui_object of some sort
- Update all efl data model to use efl_future/efl_promise
- Add proper View and Controller for Genlist/Gengrid (see D3952 for some ideas)
- There is still a large amount of .eo in elementary that are in elm
namespace. This shouldn't be installed nor appear anywhere in the
hierarchy.
- Finish porting some of the widget to Efl.Ui namespace (photocam,
index, entry, button, calendar, clock, menu, ...). This needs to be
clarified with some pending patch in phab.

This are quite a large todo list to be done with, hopefully it will...
-- 
Cedric BAIL

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel