Hi Gustavo On Tuesday 26 April 2011 10:37, Gustavo Sverzut Barbieri wrote : > > It's useless to expose such details, as we don't even write C code > that uses it. Just bind ecore_evas and you'll be fine. yeah right, please don't be reductive enlightenment.org says Evas is a canvas display library, state aware ... I'm sure you know what we are talking about. assume I want to write a game, or an animated graph library, can I code and ruby and chose my tools ? > > Moreover, bindings should try to integrate nicely with environment, > not blindly write code. For example, never expose eina_list, use > Ruby's builtin list instead. Same for hash, stringshares and all. integrate nicely is the goal, wait a little bit more it's 0.0.2 now. blindly write code ... Hallelujah I see again ! FFI philosophy is to access C API "AS IS" and to access it through ruby code, so it is portable between ruby VM implementations (MRI,JRuby,rubinius,...) if you want to use ruby array instead of eina_list you'll have to write C code to glue them together which is another type of project. > > Jérémy even mentioned Ecore_Getopt, which is a bad example given that > most high level languages have such thing nicely exposed... at least > it is the case with Python (that I used optparse as base to create > Ecore_Getopt). once again use what you want, some might even prefer getopt(3) than Evas_Getopt ?!?! btw Evas_Getopt was an exercice for me as it's the first time I use ruby-ffi and it was an excellent one to test struct mapping!
so shall I continue to expose the whole efl stack so people can access efl full power or must I only expose the elementary top level widgets so one can write GUI for it's mobile phone ?? regards ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
