On 12/09/2013 10:28 AM, Yakov Goldberg wrote: > On 12/08/2013 01:26 PM, Davide Andreoli wrote: >> 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 */ >> }; > Thanks for comments. > Looks like it's good idea to do smth like that. But some conversion API > from > Elm_Map_Overlay to python object should be implemented. Maybe the conversion of the Elm_Map_Overlay will need to be done manually because of its complexity. At least at the beginning. By the way, this structure is private to elementary so you will never have it public from Python :P And most of (or maybe all) the functions using this overlay don't receive an object as parameter. It means that Eolian will not support this kind of bindings.
Concerning the lists of basic types/Eo*, a types conversion inside the bindings layer will do the work. >> but this can be tricky for more complex types, how we describe a C array of >> strings? > Could you please give an example, which API does use it? >> 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 >> > ------------------------------------------------------------------------------ > 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
