2013/12/9 Yakov Goldberg <yako...@samsung.com> > 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. > > > > 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? >
void elm_calendar_weekdays_names_set (Evas_Object *obj, const char *weekdays[]) const char ** elm_calendar_weekdays_names_get (const Evas_Object *obj) or void elm_win_available_profiles_set<https://build.enlightenment.org/job/nightly_elm_gcc_x86_64/lastSuccessfulBuild/artifact/doc/html/group__Win.html#ga10651320469fa65120e13b184b6ea22f>(Evas_Object *obj, const char **profiles, unsigned int count) Eina_Bool elm_win_available_profiles_get<https://build.enlightenment.org/job/nightly_elm_gcc_x86_64/lastSuccessfulBuild/artifact/doc/html/group__Win.html#ga7daccafee67b5c68427b3a9ddd56171a>(Evas_Object *obj, char ***profiles, unsigned int *count) > > 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
