On Wed, Oct 31, 2012 at 1:03 PM, Gustavo Lima Chaves <[email protected]> wrote: > * Cedric BAIL <[email protected]> [2012-10-31 11:38:52 +0900]: > >> On Wed, Oct 31, 2012 at 11:23 AM, Gustavo Sverzut Barbieri >> <[email protected]> wrote: >> > On Tue, Oct 30, 2012 at 11:53 PM, Cedric BAIL <[email protected]> wrote: >> >> Hello, >> >> >> >> On Wed, Oct 31, 2012 at 1:10 AM, Christophe Dumez >> >> <[email protected]> wrote: >> >>>> There are lots of concerns from EFL developers (me included) on how >> >>>> the development of WebKit-EFL is being done. The API of webkit2 even >> >>>> not being fully supported by EFL, as contrary to webkit1. There's only >> >>>> 1 developer that seemed to care and started to send patches to >> >>>> elm-web, so webkit2 can be fully supported. >> >>>> >> >>>> No surprise there was feedback asking for clarifications and why a >> >>>> simpler api couldn't be used. Now you come and say WebKit1 is being >> >>>> deprecated. -1000 here, until the day webkit2 gets fully supported in >> >>>> EFL and you start to interact more with EFL devs. >> >>> >> >>> The proposed date for dropping WK1 EFL from upstream is 8 month away. I >> >>> think this >> >>> gives a reasonable amount of time for people currently relying on WK1 >> >>> EFL to port their code to WK2 EFL. >> >>> If anything, this should motivate people to make sure all the components >> >>> work with WK2 EFL. >> >> >> >> 8 months is clearly to short from now is clearly to short. 8 months >> >> after WK2 EFL API is stabilized and "released" (I mean by that, that >> >> any API/ABI break of it will be forbidden). Then you can consider >> >> dropping WK1 EFL. Announcing that you will drop WK1 EFL when WK2 EFL >> >> is not even stable, is not a proper move in my opinion. >> >> >> >> Upstream EFL does use WK1 EFL in the 1.7.x branch, that will be used >> >> by E17 release later this year. This means that all distribution that >> >> do want to package EFL with a stable release for E17 will be depending >> >> on WK1 EFL. You can stop development, only do bugfixes, but removing >> >> it is clearly not a smart move here. >> >> >> >>> About interaction with EFL developers, I don't think we have any problem >> >>> answering questions related >> >>> to WebKit EFL (via this mailing list or the IRC channel) or fix bugs >> >>> filed upstream against WebKit EFL. >> >> >> >> Yes, you have. I am aware of the move to WK2 EFL since less than 3 >> >> weeks. If some nice Samsung guy didn't try to help EFL upstream to >> >> move away of WK1 EFL we wouldn't be even have any proper information >> >> and code here. At this point, the WebKit EFL people need to get more >> >> involved with EFL. It's not a matter of answering question, it's about >> >> using the same tool and do that efficiently ! If we don't share >> >> infromation more effectively, this kind of thread is going to repeat. >> >> I strongly encourage every developer of WK EFL to join e-devel mailing >> >> list and ping people there when there is important subject to bring in >> >> (like new dependencies, feature request, ...). I am now subscribed to >> >> this mailing list and will try to keep reading it, but that's not >> >> enough. WK EFL team should get more engadged with EFL developer in >> >> general. >> > >> > As a related note: although Ecore provides curl/http, WebKit still >> > uses the crap alien that is libsoup. Why not start the Webkit + EFL >> > adding the missing bits to Ecore_Con and then using it natively in >> > WebKit, instead of forcing glib-mainloop integration for nothing? >> >> I can't but only agree and wish for that to happen soon. > > +1 here. Then it would be just cairo on the gtk land, I guess.
what about using enesim instead of cairo ? The rendering of esvg is faster than with librsvg, and is much more powerful, and it is not optimized, so plenty of room for improvements Vincent ------------------------------------------------------------------------------ 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_sfd2d_oct _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
