On 12/09/14 14:11, Jean Rene Dawin wrote:
> Daniel Kolesa wrote on Thu 11/09/14 12:09:
>> 2014-09-11 12:00 GMT+01:00 Jean Rene Dawin <jda...@math.uni-bielefeld.de>:
>>
>>> On Mon, Sep 08, 2014 at 04:42:04PM +0300, Daniel Zaoui wrote:
>>>> Hi,
>>>>
>>>> On 09/08/14 16:16, Jean Rene Dawin wrote:
>>>>> On Sat, Aug 16, 2014 at 02:36:10PM +0900, Carsten Haitzler wrote:
>>>>>> About time i got back to blogging about EFL etc.
>>>>>>
>>>>>>
>>> https://phab.enlightenment.org/phame/live/1//post/yet_another_c_object_model_but_better/
>>>>>>
>>>>> Hi,
>>>>>
>>>>> thanks for the explanations. Trying to reproduce the steps, the result
>>> of my tst.c
>>>>> differd a bit, though. I didn't get
>>>>>
>>>>>      EOLIAN static void
>>>>>      _tst_eo_base_constructor(Eo *obj, Tst_Data *pd)
>>>>>      {
>>>>>         eo_do_super(obj, TST_CLASS, eo_constructor());
>>>>>      }
>>>>>
>>>>>      EOLIAN static void
>>>>>      _tst_eo_base_destructor(Eo *obj, Tst_Data *pd)
>>>>>      {
>>>>>         eo_do_super(obj, TST_CLASS, eo_destructor());
>>>>>      }
>>>>>
>>>>> but instead
>>>>>
>>>>>      EOLIAN static void
>>>>>      _tst_class_constructor(Eo_Class *klass)
>>>>>      {
>>>>>      }
>>>>>      EOLIAN static void
>>>>>      _tst_class_destructor(Eo_Class *klass)
>>>>>      {
>>>>>      }
>>>>>
>>>>> Is there a more detailed documentation of the Eo-Syntax and API
>>> somewhere?
>>>>> Becuase the one on docs.enlightenment.org is not so verbose or maybe
>>> outdated.
>>>>> Is this because there will be more changes to Eo and things are not
>>> fixed yet?
>>>>>
>>>>> Thanks for your help,
>>>>>
>>>>> Jean Rene Dawin
>>>>>
>>>>
>>>> You should try with Base.constructor instead of class.constructor (same
>>>> for the destructor).
>>>>
>>>> You can look at https://phab.enlightenment.org/w/eolian/ for more docs
>>>> on the syntax.
>>>>
>>>> One of all the EFL Daniels
>>>
>>> Hi,
>>>
>>> thanks for the answers. The site you mentioned is indeed very informative
>>> about eo-file syntax. But what I'm more interested in is the whole
>>> mechanics of eo_add, eo_do and eo_add_custom and all those functions. For
>>> example I tried to do this
>>>
>>>      #define EFL_BETA_API_SUPPORT
>>>      #define EFL_EO_API_SUPPORT
>>>      #include <Elementary.h>
>>>      EAPI_MAIN int
>>>      elm_main(int argc, char **argv){
>>>          eo_init();
>>>          Eo *win = eo_add(ELM_WIN_CLASS, NULL);
>>>          eo_do(win,
>>>              elm_obj_win_title_set("Nikotinamiddinukleotidphosphat")
>>>          );
>>>          elm_run();
>>>          return 0;
>>>      }
>>>      ELM_MAIN()
>>>
>>> and while it compiled fine it threw runtime errors like
>>>
>>>      ERR<818>:eo lib/eo/eo.c:1572 eo_error_set_internal() Error with obj
>>> '0x9500b30' at elm_win.c:3510.
>>>      ERR<818>:elementary elm_win.c:3511 _elm_win_eo_base_constructor() only
>>> custom constructor can be used with 'Elm_Win' class
>>>      ERR<818>:eo lib/eo/eo.c:953 _eo_add_internal_end() Object of class
>>> 'Elm_Win' - Not all of the object constructors have been executed.
>>>
>>> as I'm obviously using Eo/Elementary in a wrong manner, but I find it
>>> quite hard to understand from the source files like Eo.h, how it would be
>>> done the right way.
>>> So, I guess I will have to try harder :)
>>>
>>
>> You're supposed to use elm_win_add at this point to create the object. The
>> base constructor is explicitly overloaded to trigger this error.
>> Alternatively, you can use "eo_add_custom(ELM_WIN_CLASS, NULL,
>> elm_obj_win_constructor("foo", ELM_WIN_BASIC));". But that's pretty much
>> identical to what the "elm_win_add" function does.
>
> Ah, ok. Does "at this point" mean at the current state of the Eo 
> implementation for
> Elementary? Is it planned to replace functions like evas_object_show() with
> Eo style functions, or are they planned to coexist?
>
> Thanks for the explanations,

Very good question. I'd first look at
https://phab.enlightenment.org/w/efl_interfaces/
where I document my efforts.

As for your question, many things will change. The first thing that will 
change is the functions themselves, for example redundant functions 
(part_text_set all over the place) will disappear and become just one 
function overridden for inheriting classes.
Additionally, some functions will just die or completely replaced. We 
are trying to make things more property (set/get clones) oriented to 
more bindable. All of this should be getting there with time.

As for the current EFL API, e.g. evas_object_show, it'll co-exist for a 
while. It'll die once we switch to EFL 2.0.

--
Tom.


------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to