On Tue, Mar 29, 2016 at 11:05 AM, Davide Andreoli <[email protected]> wrote: > 2016-03-16 12:54 GMT+01:00 Amitesh Singh <[email protected]>: >> On Mar 15, 2016 8:00 AM, "Carsten Haitzler" <[email protected]> wrote: >> > On Mon, 14 Mar 2016 13:35:04 -0700 Cedric BAIL <[email protected]> >> > said: >> > >> > > On Mon, Mar 14, 2016 at 7:27 AM, Felipe Magno de Almeida >> > > <[email protected]> wrote: >> > > > On Mon, Mar 14, 2016 at 2:07 AM, Carsten Haitzler < >> [email protected]> >> > > > wrote: >> > > >> so now eo api and efl look the same... work the same. why keep eo >> api as >> > > >> eo_ ? why not just move it into efl_ space :) i see no reason to >> keep it >> > > >> separate. it's just confusing. is what iw ant in eo_ or in efl_ ? >> > > >> >> > > >> either that or we move all efl_* space to eo_* - either way .. why >> keep >> > > >> both? why make people have to figure out where something comes from >> before >> > > >> they can use it? >> > > >> > > You have my support for this. Nobody reacted possitively when I >> > > proposed that, but I don't see the point of the eo namespace in efl >> > > interface. >> > >> > not noew that we have eo 4. there is nothing special about eo vs efl >> > now. >> it's >> > all: >> > >> > xxx_blahblah(obj,...); >> > >> > if it's eo or it's efl. it's all the same. i dont see code like: >> > >> > o = eo_add(xxx); >> > efl_blah_set(o, ...); >> > eo_ref(o); >> > ... >> > >> > to be nice. we use 2 namespaces to address the same object. >> > >> >> I agree with raster on this. It's not that nice to use 2 namespaces to >> address same object. >> Efl_object _ add seems nice to me. Any takers? :) > > hmm, I'm facing an issue right now that is related to this discussion, > (me working on eolian generated python bindings) > > in current python-efl the user use the efl libs as: > from efl import elm > bt = elm.Button(...) > > so the button is namespaced as: efl.elm.Button (efl is the main package) > > Now the new efl interfaces will become namspaced as: > efl.efl.gfx.Base > > obviously the double efl at the start isn't so good and is quite > confusing.... > > So the problem here is that we have a namespace (efl) that is the same > as the project name.... in a tree: > - efl > --- ecore > --- evas
Both Ecore and Evas namespace should disapear. Ecore most likely completely and Evas will become Efl.Canvas. The idea being that Efl.Canvas will have raw object with no system logic (like configuration, ...). > --- efl > ------gfx Elementary would become Efl.Ui. So the code above would be : from efl import ui bt = ui.Button(...) At least that's how I would expect it. Would it be possible to merge all of the efl namespace directly inside the efl module and "strip" that namespace ? If so, I would think that this is the way to go, no ? Cedric ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140 _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
