>-----Original Message----- >From: Tom Hacohen [mailto:tom.haco...@samsung.com] >Sent: Friday, February 22, 2013 9:41 AM >To: Eoff, Ullysses A >Cc: Enlightenment developer list; Rafael Antognolli >Subject: Re: [E-devel] Backport a new Ecore_Wayland feature to 1.7.x? > >On 22/02/13 17:29, Eoff, Ullysses A wrote: >>> -----Original Message----- >>> From: Tom Hacohen [mailto:tom.haco...@samsung.com] >>> Sent: Friday, February 22, 2013 9:17 AM >>> To: Enlightenment developer list >>> Cc: Rafael Antognolli; Eoff, Ullysses A >>> Subject: Re: [E-devel] Backport a new Ecore_Wayland feature to 1.7.x? >>> >>> On 22/02/13 17:07, Rafael Antognolli wrote: >>>> I know that it's a feature addition, but considering that it's to >>>> enable better testing of the 1.7.x branch, I would let it go in. >>>> >>>> Does anyone have something against it? >>>> >>> >>> Just to clarify: is it new "outside" features, or do they modify things? >>> I.e is it a new API that were just added to query stuff, or is it API >>> that actually modifies/touches current internals? >>> >>> Because if it's the latter, I'm quite wary about it. >>> >> >> It is a new API for querying stuff... it does not modify the pre-existing >> internal functionality. > >I just took a look at the code, and it does change internals. You create >and free the globals var inside an existing function, that means that if >there's a flaw in your code, ecore will be less stable. This code looks >harmless to me too, but since it does touch internals, I'm not sure >about it. With that being said, I don't mind if this goes in, I just >don't want to create a precedence. >
Yes, of course, the data needs to be initialized and destroyed for the new feature, hence that much was added to the existing init and destroy functions in the Wayland engine code. >What do you need it for anyway? I mean, if it's for developers, >developers should just apply this patch locally... An alternative thing >to consider, is to wait until early next week when we'll most likely >migrate the legacy efl dirs and then add your own 1.7 for wayland devs >branch. I just don't see the point of having it in core branch. > This feature will allow users of the EFL/Wayland API to take advantage of custom Wayland protocol extensions. The Wayland global protocols need to be accessible for that to work. In my case, it's so that I can write automated functional tests that need to bind to a custom Wayland test protocol extension to do more aggressive validation of EFL/Wayland functionality. But, I don't see why an EFL/Wayland application developer couldn't take advantage of it, too, without forcing them to do a custom EFL compilation. >-- >Tom. ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
