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