On Wed, Sep 21, 2016 at 11:33 AM, Tom Hacohen <t...@osg.samsung.com> wrote:
> On 21/09/16 15:10, Gustavo Sverzut Barbieri wrote:
>> On Wed, Sep 21, 2016 at 5:26 AM, Tom Hacohen <t...@osg.samsung.com> 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<x> 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
>> "<NAMESPACE>_${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.

no, it's not an UI language.. although I did use only UI objects, the
idea is that I don't have to manually type lines that are 160 chars
wide due namespace... not to say manually resolve all the methods to
proper namespaces myself, like in the example above I know there is a
"pack()" method, the tool should find out where it is declared, not me
having to search all efl_*.eo to find.

I'd love to rewrite src/examples/ecore/efl_*.c to use that generator,
currently a big part of that code is solely creating and setting
properties on the dialers/readers/writers, then linking one to
another. If all I had to do is parse cmdline and define my callbacks,
it would be much easier.

Also note that it would simply the callbacks for me... unlike you said
above, it's not convenient to use "const Efl_Event *" myself... if the
tool could expand that to proper parameters, would save me time and
make it less error prone, like an event that delivers me an error code
should expand to:

void cb(void *data, Eo *o, Eina_Error error) { }

An event that delivers a 2 strings (key/value):

void cb(void *data, Eo *o, const char *key, const char *value) { }

or at least the event payload struct:

void cb(void *data, Eo *o, const My_Key_Value kv);

the tool would generate the actual event callback, get data from
Efl_Event and then call my function

Gustavo Sverzut Barbieri
Mobile: +55 (16) 99354-9890

enlightenment-devel mailing list

Reply via email to