Hello,

On Tue, Nov 5, 2013 at 12:42 AM, Yakov Goldberg <yako...@samsung.com> wrote:
> Here is autogenerated (a little prettyfied and shortened) example of eo
> file.
> http://pastebin.com/ERQphzNk
> I'm using my own python code from eo_bindings, where I was parsing c/h
> files to get all eo information.
>
> Some explanations:
> "name" - class name from Eo class description. We check that it is unique.
> "inherits" - names of parent classes
> "constructors" - (actually it is a method, just put it into separate
> section). Here you will meet only custom cunstructors.
>     here "win_constructor" is a name
>              "comment" - comment
>              parameters:    2d array
>             ["in","const","char*","name",""],
>                  direction, modifier, type, name, comment
>                 maybe modifier is not needed, (but I already parsed it)

I must say that I don't like the parameters syntax at all. I think
something along the following line would have been better :
in : [ { "name" : "const char *" } ]. Also I am starting thinking that
we should have comment in doxygen form inside the JSON itself that
could then be put along the generated code.

For example "item_insert_before" would become :

    "item_insert_before": {
/* This inserts an item before another in the list. It will be in the
 * same tree level or group as the item it is inserted before.
 *
 * @see elm_genlist_item_append()
 * @see elm_genlist_item_prepend()
 * @see elm_genlist_item_insert_after()
 * @see elm_object_item_del()
 *
 * @ingroup Genlist
 */
      "brief": "Insert an item before another in a genlist widget",
      "parameters": [
        in : [
               { "itc" : "const Elm_Genlist_Item_Class*" }, /* @param
itc The item class for the item */
               { "data" : "const void*" }, /* @param data The item data */
               { "parent" : "Elm_Object_Item*" }, /* @param parent The
parent item, or NULL if none */
               { "before_it" : "Elm_Object_Item*" }, /* @param before
The item to place this new one before. */
               { "type" : "Elm_Genlist_Item_Type" }, /* @param type Item type */
               { "func" : "Evas_Smart_Cb" }, /* @param func
Convenience function called when the item is selected */
               { "func_data" : "const void *" } /* @param func_data
Data passed to @p func above. */
              ],
        out : [
               { "ret" : "Elm_Object_Item*" } /* @return A handle to
the item added or @c NULL if not possible */
               ]
        ]
      ]
    },

> Properties.
>     Property can be set/get; only set, only get; this is saved in "type"
> field: "rw"(or no tag), "ro", "wo".
>     How do I determine the type? If all parameters are "in" for some
> func which ends with "_set"
>     and are "out" for some func which ends with "_get" this will be
> set/get property. If this condition fails, they will be methods.

Same for property we should be fine with something like :
"keyboard_win": {
      "brief": "whether the window is a keyboard.",
      "access": "rw",
      "parameters": [
        [ { "is_keyboard" : "Eina_Bool" } ]
      ]

> Methods: the same as properties, but with direction of parameter.
>
> Implements: list of overloaded functions:
>               ["class name" , "func_name", "func_type"]
> Some comments: We need to have "func_type" here.
> suppose we have func "color" and property "color" in parent class,
> and want to overload color_set property in child class, so we will have:
> ["parent_class", "color", "set"]
>
> "signals" - it's easy, if all events will work only through eo we need
> only "event_name" and "description"

Nop, we need also to describe the structure of the information that is
send along the event or we will not be able to generate any bindings
for event automatically. Arguably it's maybe not a real problem as
there should not be to many events, but still worth thinking about
that.
-- 
Cedric BAIL

------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to