2016-09-22 0:45 GMT+02:00 Gustavo Sverzut Barbieri <barbi...@gmail.com>:
> 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'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
> >> "<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
> 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
