2013/12/8 Yakov Goldberg <yako...@samsung.com>
> So, as soon as "Ragel Strikes Back"
> here is " Elm_Image" in Jeremy's format.
> http://pastebin.com/xptFf6y0
>
> Properties and Methods are as Jeremy described.
> And in the end you can also find "implements" and "signals".
>
> Just one suggestion: lets move "implements" content into "properties"
> and "methods":
>
> methods{
> some_method {
> ...
> };
> Evas_Smart :: show;
> };
>
> ...only some comments about properties.
> If we want to override , only setter or getter we need to specify "set"
> or "get".
> If you have better ideas about syntax, please suggest.
> properties{
> some_prop {
> ...
> };
> Evas_Object :: color;
> Evas_Object :: size :: set;
> Evas_Object :: visibility :: get;
> };
> ======================================
>
> Some additional question.
> Here is some part of ElmFileselector.eo file.
> You can see "selected_set" and "selected_get" are described as methods.
> Why? Because I generate, this eo file, by parsing descriptions of eo
> classes.
> If there are two functions which have:
> - the same name with "set/get" suffix;
> - the same number of parameters;
> - all parameters are "in" for "set"
> - all parameters are "out" for "get"
> it will be described as property; (or "only_set"/"only_get" property)
> if one of these rules fails, functions will be generated as methods.
>
> Because of legacy, "selected_set" func returns, so here I generate it as
> method.
>
> methods {
> selected_set {
> /*@ Set, programmatically, the currently selected file/directory
> in the given file selector widget */
> return Eina_Bool;
> params {
> in const char* path; /*@ */
> };
> };
> selected_get {
> /*@ Get the currently selected item's (full) path, in the given
> file the given file selector widget */
> return const char*;
> params {
> };
> };
> }
>
>
> But maybe, as soon as it is almost property (only one "ret" gets in the
> way here), we can describe it as property, which returns some value.
> "selected": {
> "set": {
> "return" : "Eina_Bool",
> "comment": "Set, programmatically, the currently selected
> file/directory in the given file selector widget"
> },
> "get": {
> "comment": "Get the currently selected item's (full) path, in
> the given file the given file selector widget"
> },
> "parameters": [
> {
> "path": ["const char*", ""]
> }
> ]
> },
>
> We will generate Eo and C - legacy functions as they are now.
> eo macro: "selected_set" EO_TYPECHECK (path, const char*) EO_TYPECHECK
> (ret, Eina_Bool *)
> eo macro: "selected_get" EO_TYPECHECK (path, const char**)
> legacy: Eina_Bool elm_fileselector_selected_set(Eo * obj, const char*
> path)
> legacy: const char * elm_fileselector_selected_get(Eo * obj)
>
> And C++, python and other bindings will ignore ret in setters/getters and
> use it as property:
> fileselector.path = "/root/some/path/filename"
>
>
> So the question is:
> should we treat it like this, or leave it as methods?
>
> Yakov.
>
>
Hi all,
I have one main concern about the generation of bindings using the eo file:
how we like to manage complex types (see Eina_List) in the target language?
(python for example)
As the py bindings are implemented now (and I really like this!), we do not
provide bindings for eina types, but we convert to the corresponding python
type for the user.
For example:
Elm_Map {
{
property {
overlays {
get {
/*@ get a list of all the overlays in the map */
};
params {
Eina_List overlays; /*@ actually a list of Elm_Map_Overlay objs
*/
};
};
};
};
In this case we don't know what the eina_list "overlays" contain thus we
cannot automatically convert to the corresponding python list of object.
Other example of complex types I found to be used in the current bindings
are C array (usually with strings inside).
How can we solve this?
we could add the content of the complex type in the eo files:
params {
Eina_List(Elm_Map_Overlay) overlays; /*@ ...or a different syntax */
};
params {
Eina_List(char *) names; /*@ ...for an eina list of strings */
};
but this can be tricky for more complex types, how we describe a C array of
strings?
what do you guys think?
regards
davemds
>
>
>
>
> ------------------------------------------------------------------------------
> Sponsored by Intel(R) XDK
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
>
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
------------------------------------------------------------------------------
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
