On Tue, Apr 26, 2011 at 8:09 PM, Jérémy Zurcher <[email protected]> wrote:
> 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 ?
In very rare cases you'll create the Evas* with evas itself. Often
what you use is ecore_evas_new() then get the Evas* with
ecore_evas_get(). The functions you and raster mentioned are useless
for 99.99999999% of the code, as it's already done inside Ecore_Evas
itself.
>> 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.
Do it. It is really, really annoying to get Eina_List from a language
that have builtin list types, such as JavaScript, Python or Ruby.
>> 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!
Forget about it and do something more useful, Elementary is a good start.
Ecore_Getopt is more powerful than regular getopt as it will do type
parsing (bool, int, string, lists) as well as generate help output.
But most highlevel languages provide something like this. I don't know
about Ruby, but it may have something equivalent to Python's optparse
(again, I translated Python's optparse to C and it's Ecore_Getopt).
> 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 ??
The level should be Elementary -> Evas -> Ecore -> Edje. But be
selective about evas, you first need basic Evas_Object* manipulation,
like
evas_object_{move,resize,del,show,hide,clip_set,clip_unset,color_set,color_get,geometry_get,visible_get...}.
Then some very-often used objects like (in order) rectangle, image,
text... you likely will never use textblock from Ruby, as it's so
complex it's better to use it from Edje/Elementary. Ecore you first
need some main loop operations like ecore_timer_*, ecore_animator_*,
ecore_idler_*... Then some ecore_evas (but most of it is handled
inside elm_win_add()). Edje is simple and useful, but many functions
are already covered by elementary wrappers in elm_layout.
Also, note that some functions are not actually functions but
static-inline or macros, you should expose those as well.
And last but not least, try to provide common Ruby constructions with
EFL, so Ruby developers will feel comfortable. In Python we did a
C-like version (obj.color_set(r, g, b, a)) and a Pythonic version
(obj.color = (r, g, b, a)), as well as helpers like obj.center and
similar.
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: [email protected]
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
