Re: [E-devel] [webkit-efl] ewebkit 1.11.- alpha 1
Thanks a lot for the effrot! This must be the very good historical step. I gotta try it. Thanks. Daniel Juyung Seo (SeoZ) On Tue, Aug 5, 2014 at 10:11 PM, ryuan Choi wrote: > > = Ewebkit 1.11 alpha taballs = > > I'd like to share new ewebkit tarball as the first attempt to release > ewebkit library. > > Although version is 1.11 like EFL and Elementary, I think that it's still > unstable. > So, I hope that there are many requirements and tests (and supports). > > == Source == > https://github.com/ewebkit/webkit > branch : ewebkit-1.11 > (master branch is for sync with webkit.org) > > == Download == > > > http://download.enlightenment.org/rel/libs/webkit-efl/ewebkit-1.11.0-alpha1.tar.gz > 58ae62aeab25a8dfddd3b377d6f6503a525f8df3164207e26d1da216a293bd4b > > > http://download.enlightenment.org/rel/libs/webkit-efl/ewebkit-1.11.0-alpha1.tar.xz > 3392b1d2e8b9acd9e0461f8235c22fde42420ae4e6c964aa7ec33695d3ceb10c > > > == NEWS == > From the previous snapshot, > > * WebKit1/EFL was dropped. > * fixed color picker bug () > * refactor vibration API. > * Add ewk_application_cache_manager APIs > * Add an API to set process model > * Add ewk APIs to control TLS error policy on WebContext > * Add ewk_view_bg_color_set > * Add API to get contents size of current web page. > * Removed NETWORK_INFO. > * Refactor favicon database APIs > * Add ewk_view_fixed_layout_size_set|get() > * Use default context for ewk_view_add > * Change ewk_view_settings_get to ewk_page_group_settings_get > * Add new Public API in ewk_download_job.h to get size of the data > already downloaded. > * Add a "focus,notfound" signal. > * Provide VERSION information in EWebKit2.h like EFL and Elementary. > * Media Control of video tag is changed from edj to HTML/javascript. > * Enable CSS Filter > * Turn off Indexed Database > > And many common webkit(WebCore,JSC) changes. > > ___ > webkit-efl mailing list > webkit-...@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-efl > > -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [webkit-efl] Consideration about first release of ewebkit
I created https://bugs.webkit.org/show_bug.cgi?id=135487 to bump ewebkit version. And, created https://github.com/ewebkit If someone want to make changes, please let me know with your github username. If you also know some patch which is not merged but I should cherry-pick, please let me know. Thanks for your support. Ryuan choi 2014. 8. 1. 오전 10:44에 "Cedric BAIL" 님이 작성: > Hello, > > On Thu, Jul 31, 2014 at 11:39 PM, ryuan Choi > wrote: > > I need your opinion about first version of ewebkit. > > > > ewebkit was always under development without any version. > > (always 0.1.0) > > > > Within this state (almost 4 years I joined), we made ewebkit1, made > ewebkit2 > > and dropped ewebkit1. > > Because I am still newbie, I don't know the level for stable version. > > But, I think that we might not release ewebkit ever if we want more > stable > > version. > > About few months, we didn't have any big changes in ewebkit2 interface. > > (Only one big news was dropping ewebkit1) > > Our almost work was following changes of webkit.org.(build fix or > > regression) > > > > EFL 1.11 will be released after few days later. > > > > So, what do you think about releasing first version of ewebkit as 1.11 > (or > > any suggestion?) > > > > My simple idea is > > 1. when second merge window of EFL is over, bump the version of ewebkit > in > > the webkit trunk(webkit.org) > > 2. sync and fork that to the version branch in github. > > 3. clear some code if needed. > > - disable features which are still unstable or under development. > > - cherry-pick patches which are still under review but very important > > for ewebkit. > > 4. test and fix some critical bugs within last three stabilization phase > of > > EFL. > > 5. When new version of EFL is released, tag the version like EFL. > > 6. After released, only hot fix is allowed in the version branch for the > > minor release. > > > > > > In a short, > > - sync the release process with EFL after second merge window is over. > > - develop the ewebkit in the trunk(webkit.org) always like current > sitation. > > - maintain the version branch for the hot fix(crash, ...) > > > > What do you think about it? > > You just made my day way better ! It's a very good proposal that I am > all for it. I think we can also all agree here that you are going to > be the release manager for ewebkit. Do you have all the needed access > for doing the release on enlightenment server ? > -- > Cedric BAIL > ___ > webkit-efl mailing list > webkit-...@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-efl > -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [webkit-efl] Consideration about first release of ewebkit
Hello, On Thu, Jul 31, 2014 at 11:39 PM, ryuan Choi wrote: > I need your opinion about first version of ewebkit. > > ewebkit was always under development without any version. > (always 0.1.0) > > Within this state (almost 4 years I joined), we made ewebkit1, made ewebkit2 > and dropped ewebkit1. > Because I am still newbie, I don't know the level for stable version. > But, I think that we might not release ewebkit ever if we want more stable > version. > About few months, we didn't have any big changes in ewebkit2 interface. > (Only one big news was dropping ewebkit1) > Our almost work was following changes of webkit.org.(build fix or > regression) > > EFL 1.11 will be released after few days later. > > So, what do you think about releasing first version of ewebkit as 1.11 (or > any suggestion?) > > My simple idea is > 1. when second merge window of EFL is over, bump the version of ewebkit in > the webkit trunk(webkit.org) > 2. sync and fork that to the version branch in github. > 3. clear some code if needed. > - disable features which are still unstable or under development. > - cherry-pick patches which are still under review but very important > for ewebkit. > 4. test and fix some critical bugs within last three stabilization phase of > EFL. > 5. When new version of EFL is released, tag the version like EFL. > 6. After released, only hot fix is allowed in the version branch for the > minor release. > > > In a short, > - sync the release process with EFL after second merge window is over. > - develop the ewebkit in the trunk(webkit.org) always like current sitation. > - maintain the version branch for the hot fix(crash, ...) > > What do you think about it? You just made my day way better ! It's a very good proposal that I am all for it. I think we can also all agree here that you are going to be the release manager for ewebkit. Do you have all the needed access for doing the release on enlightenment server ? -- Cedric BAIL -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [webkit-efl] Stop to maintain EFL WK1 port
On Thu, 3 Jul 2014 20:27:27 +0900 ryuan Choi said: > Yep, I will keep webkit2 support (as the backend of elm_web) and improve it > more and more. > > Until you kick elm_web out. :) cool. that sounds good. and actually no desire to kick elm_web out. if anything we should use it more... :) > 2014-07-03 9:21 GMT+09:00 Carsten Haitzler : > > > On Wed, 2 Jul 2014 20:59:16 +0900 ryuan Choi said: > > > > > Hi. > > > > > > It might be possible to refactor ewebkit2 to use EFL++ directly after > > > dropping the support of the lower version of EFL. > > > > > > But in my two cents, it's not important. > > > Unfortunately, ewebkit2 developers not familiar with the latest EFL > > > changes. They only have small experience with the EFL on the tizen. > > > (me too. :/ ) > > > > > > By the way, I removed(and checked) the all of WebKit1/Efl (ewebkit) code > > > from the webkit.org repository. > > > (https://bugs.webkit.org/show_bug.cgi?id=134087) > > > Should(Can) I remove ewebkit backend for elm_web ? > > > > you mean remove just the webkitefl for webkit1 support in elm_web - keep > > wenkit2 support... right? > > > > > Best Regards, > > > Ryuan Choi > > > > > > > > > > > > 2014-07-01 18:39 GMT+09:00 Carsten Haitzler : > > > > > > > On Wed, 25 Jun 2014 12:44:19 -0300 Felipe Magno de Almeida > > > > said: > > > > > > > > > On Sat, Jun 21, 2014 at 1:20 AM, Cedric BAIL > > > > > > wrote: > > > > > > On Jun 21, 2014 2:26 AM, "Carsten Haitzler" > > > > wrote: > > > > > >> On Fri, 20 Jun 2014 21:25:54 -0300 Felipe Magno de Almeida > > > > > >> said: > > > > > >> > On Fri, Jun 20, 2014 at 9:07 PM, Carsten Haitzler < > > > > ras...@rasterman.com> > > > > > >> > wrote: > > > > > >> > > On Fri, 20 Jun 2014 15:02:37 -0300 Felipe Magno de Almeida > > > > > >> > > said: > > > > > > > > > > [snip] > > > > > > > > > > >> > I think it would make the port easier to mantain. It would give > > > > RAII, > > > > > >> > STL-compatibility, easier callback support with lambda-support > > and a > > > > > >> > value-based API. But that's just my opinion. > > > > > >> > > > > > >> elm web has a c api. will always have one. thus we then would > > have to > > > > > > write a c+ > > > > > >> + elm web by hand AND a c+eo one. no. use eo to write one and > > efl++ > > > > > > exposes elm > > > > > >> web. webkit api is internal then and thats how it should be. > > > > > > > > > > > > I think Felipe was referring to the internal of WebKit talking to > > efl > > > > which > > > > > > is already in c++ and would likely benefit from using the c++ with > > no > > > > > > penalty. > > > > > > > > > > Exactly. Sorry for not being clear. I didn't mean use EFL++ for the > > > > > elm_web, but for the WebKit backend for EFL. There's no reason to use > > > > > the C EFL API by C++ code, IMO. > > > > > > > > oh - then i don't know .. but i suspect the code is already done and > > using > > > > efl's c interface inside the c++ code as that is working today already. > > > > > > > > -- > > > > - Codito, ergo sum - "I code, therefore I am" > > -- > > > > The Rasterman (Carsten Haitzler)ras...@rasterman.com > > > > > > > > > > > > > > > > > > -- > > > > Open source business process management suite built on Java and Eclipse > > > > Turn processes into business applications with Bonita BPM Community > > Edition > > > > Quickly connect people, data, and systems into organized workflows > > > > Winner of BOSSIE, CODIE, OW2 and Gartner awards > > > > http://p.sf.net/sfu/Bonitasoft > > > > ___ > > > > enlightenment-devel mailing list > > > > enlightenment-devel@lists.sourceforge.net > > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > > -- > > > Open source business process management suite built on Java and Eclipse > > > Turn processes into business applications with Bonita BPM Community > > Edition > > > Quickly connect people, data, and systems into organized workflows > > > Winner of BOSSIE, CODIE, OW2 and Gartner awards > > > http://p.sf.net/sfu/Bonitasoft > > > ___ > > > enlightenment-devel mailing list > > > enlightenment-devel@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > > -- > > - Codito, ergo sum - "I code, therefore I am" -- > > The Rasterman (Carsten Haitzler)ras...@rasterman.com > > > > > -- > Open source business process management suite built on Java and Eclipse > Turn processes into business applications with Bonita BPM Community Edition > Quickly connect people, data, and systems into organized workflows > Winner of BOSSIE, CODIE, OW2 and Gartner awards > http://p.sf.net/sfu/Bonitas
Re: [E-devel] [webkit-efl] Stop to maintain EFL WK1 port
Yep, I will keep webkit2 support (as the backend of elm_web) and improve it more and more. Until you kick elm_web out. :) 2014-07-03 9:21 GMT+09:00 Carsten Haitzler : > On Wed, 2 Jul 2014 20:59:16 +0900 ryuan Choi said: > > > Hi. > > > > It might be possible to refactor ewebkit2 to use EFL++ directly after > > dropping the support of the lower version of EFL. > > > > But in my two cents, it's not important. > > Unfortunately, ewebkit2 developers not familiar with the latest EFL > > changes. They only have small experience with the EFL on the tizen. > > (me too. :/ ) > > > > By the way, I removed(and checked) the all of WebKit1/Efl (ewebkit) code > > from the webkit.org repository. > > (https://bugs.webkit.org/show_bug.cgi?id=134087) > > Should(Can) I remove ewebkit backend for elm_web ? > > you mean remove just the webkitefl for webkit1 support in elm_web - keep > wenkit2 support... right? > > > Best Regards, > > Ryuan Choi > > > > > > > > 2014-07-01 18:39 GMT+09:00 Carsten Haitzler : > > > > > On Wed, 25 Jun 2014 12:44:19 -0300 Felipe Magno de Almeida > > > said: > > > > > > > On Sat, Jun 21, 2014 at 1:20 AM, Cedric BAIL > > > > wrote: > > > > > On Jun 21, 2014 2:26 AM, "Carsten Haitzler" > > > wrote: > > > > >> On Fri, 20 Jun 2014 21:25:54 -0300 Felipe Magno de Almeida > > > > >> said: > > > > >> > On Fri, Jun 20, 2014 at 9:07 PM, Carsten Haitzler < > > > ras...@rasterman.com> > > > > >> > wrote: > > > > >> > > On Fri, 20 Jun 2014 15:02:37 -0300 Felipe Magno de Almeida > > > > >> > > said: > > > > > > > > [snip] > > > > > > > > >> > I think it would make the port easier to mantain. It would give > > > RAII, > > > > >> > STL-compatibility, easier callback support with lambda-support > and a > > > > >> > value-based API. But that's just my opinion. > > > > >> > > > > >> elm web has a c api. will always have one. thus we then would > have to > > > > > write a c+ > > > > >> + elm web by hand AND a c+eo one. no. use eo to write one and > efl++ > > > > > exposes elm > > > > >> web. webkit api is internal then and thats how it should be. > > > > > > > > > > I think Felipe was referring to the internal of WebKit talking to > efl > > > which > > > > > is already in c++ and would likely benefit from using the c++ with > no > > > > > penalty. > > > > > > > > Exactly. Sorry for not being clear. I didn't mean use EFL++ for the > > > > elm_web, but for the WebKit backend for EFL. There's no reason to use > > > > the C EFL API by C++ code, IMO. > > > > > > oh - then i don't know .. but i suspect the code is already done and > using > > > efl's c interface inside the c++ code as that is working today already. > > > > > > -- > > > - Codito, ergo sum - "I code, therefore I am" > -- > > > The Rasterman (Carsten Haitzler)ras...@rasterman.com > > > > > > > > > > > > > -- > > > Open source business process management suite built on Java and Eclipse > > > Turn processes into business applications with Bonita BPM Community > Edition > > > Quickly connect people, data, and systems into organized workflows > > > Winner of BOSSIE, CODIE, OW2 and Gartner awards > > > http://p.sf.net/sfu/Bonitasoft > > > ___ > > > enlightenment-devel mailing list > > > enlightenment-devel@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > -- > > Open source business process management suite built on Java and Eclipse > > Turn processes into business applications with Bonita BPM Community > Edition > > Quickly connect people, data, and systems into organized workflows > > Winner of BOSSIE, CODIE, OW2 and Gartner awards > > http://p.sf.net/sfu/Bonitasoft > > ___ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > -- > - Codito, ergo sum - "I code, therefore I am" -- > The Rasterman (Carsten Haitzler)ras...@rasterman.com > > -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [webkit-efl] Stop to maintain EFL WK1 port
On Wed, 2 Jul 2014 20:59:16 +0900 ryuan Choi said: > Hi. > > It might be possible to refactor ewebkit2 to use EFL++ directly after > dropping the support of the lower version of EFL. > > But in my two cents, it's not important. > Unfortunately, ewebkit2 developers not familiar with the latest EFL > changes. They only have small experience with the EFL on the tizen. > (me too. :/ ) > > By the way, I removed(and checked) the all of WebKit1/Efl (ewebkit) code > from the webkit.org repository. > (https://bugs.webkit.org/show_bug.cgi?id=134087) > Should(Can) I remove ewebkit backend for elm_web ? you mean remove just the webkitefl for webkit1 support in elm_web - keep wenkit2 support... right? > Best Regards, > Ryuan Choi > > > > 2014-07-01 18:39 GMT+09:00 Carsten Haitzler : > > > On Wed, 25 Jun 2014 12:44:19 -0300 Felipe Magno de Almeida > > said: > > > > > On Sat, Jun 21, 2014 at 1:20 AM, Cedric BAIL > > wrote: > > > > On Jun 21, 2014 2:26 AM, "Carsten Haitzler" > > wrote: > > > >> On Fri, 20 Jun 2014 21:25:54 -0300 Felipe Magno de Almeida > > > >> said: > > > >> > On Fri, Jun 20, 2014 at 9:07 PM, Carsten Haitzler < > > ras...@rasterman.com> > > > >> > wrote: > > > >> > > On Fri, 20 Jun 2014 15:02:37 -0300 Felipe Magno de Almeida > > > >> > > said: > > > > > > [snip] > > > > > > >> > I think it would make the port easier to mantain. It would give > > RAII, > > > >> > STL-compatibility, easier callback support with lambda-support and a > > > >> > value-based API. But that's just my opinion. > > > >> > > > >> elm web has a c api. will always have one. thus we then would have to > > > > write a c+ > > > >> + elm web by hand AND a c+eo one. no. use eo to write one and efl++ > > > > exposes elm > > > >> web. webkit api is internal then and thats how it should be. > > > > > > > > I think Felipe was referring to the internal of WebKit talking to efl > > which > > > > is already in c++ and would likely benefit from using the c++ with no > > > > penalty. > > > > > > Exactly. Sorry for not being clear. I didn't mean use EFL++ for the > > > elm_web, but for the WebKit backend for EFL. There's no reason to use > > > the C EFL API by C++ code, IMO. > > > > oh - then i don't know .. but i suspect the code is already done and using > > efl's c interface inside the c++ code as that is working today already. > > > > -- > > - Codito, ergo sum - "I code, therefore I am" -- > > The Rasterman (Carsten Haitzler)ras...@rasterman.com > > > > > > > > -- > > Open source business process management suite built on Java and Eclipse > > Turn processes into business applications with Bonita BPM Community Edition > > Quickly connect people, data, and systems into organized workflows > > Winner of BOSSIE, CODIE, OW2 and Gartner awards > > http://p.sf.net/sfu/Bonitasoft > > ___ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > -- > Open source business process management suite built on Java and Eclipse > Turn processes into business applications with Bonita BPM Community Edition > Quickly connect people, data, and systems into organized workflows > Winner of BOSSIE, CODIE, OW2 and Gartner awards > http://p.sf.net/sfu/Bonitasoft > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [webkit-efl] Stop to maintain EFL WK1 port
Hello, On Wed, Jul 2, 2014 at 1:59 PM, ryuan Choi wrote: > It might be possible to refactor ewebkit2 to use EFL++ directly after > dropping the support of the lower version of EFL. > > But in my two cents, it's not important. > Unfortunately, ewebkit2 developers not familiar with the latest EFL > changes. They only have small experience with the EFL on the tizen. > (me too. :/ ) > > By the way, I removed(and checked) the all of WebKit1/Efl (ewebkit) code > from the webkit.org repository. > (https://bugs.webkit.org/show_bug.cgi?id=134087) > Should(Can) I remove ewebkit backend for elm_web ? Yes, but please provide a new snapshot for the next release of EFL so that we have something in sync. -- Cedric BAIL -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [webkit-efl] Stop to maintain EFL WK1 port
Hi. It might be possible to refactor ewebkit2 to use EFL++ directly after dropping the support of the lower version of EFL. But in my two cents, it's not important. Unfortunately, ewebkit2 developers not familiar with the latest EFL changes. They only have small experience with the EFL on the tizen. (me too. :/ ) By the way, I removed(and checked) the all of WebKit1/Efl (ewebkit) code from the webkit.org repository. (https://bugs.webkit.org/show_bug.cgi?id=134087) Should(Can) I remove ewebkit backend for elm_web ? Best Regards, Ryuan Choi 2014-07-01 18:39 GMT+09:00 Carsten Haitzler : > On Wed, 25 Jun 2014 12:44:19 -0300 Felipe Magno de Almeida > said: > > > On Sat, Jun 21, 2014 at 1:20 AM, Cedric BAIL > wrote: > > > On Jun 21, 2014 2:26 AM, "Carsten Haitzler" > wrote: > > >> On Fri, 20 Jun 2014 21:25:54 -0300 Felipe Magno de Almeida > > >> said: > > >> > On Fri, Jun 20, 2014 at 9:07 PM, Carsten Haitzler < > ras...@rasterman.com> > > >> > wrote: > > >> > > On Fri, 20 Jun 2014 15:02:37 -0300 Felipe Magno de Almeida > > >> > > said: > > > > [snip] > > > > >> > I think it would make the port easier to mantain. It would give > RAII, > > >> > STL-compatibility, easier callback support with lambda-support and a > > >> > value-based API. But that's just my opinion. > > >> > > >> elm web has a c api. will always have one. thus we then would have to > > > write a c+ > > >> + elm web by hand AND a c+eo one. no. use eo to write one and efl++ > > > exposes elm > > >> web. webkit api is internal then and thats how it should be. > > > > > > I think Felipe was referring to the internal of WebKit talking to efl > which > > > is already in c++ and would likely benefit from using the c++ with no > > > penalty. > > > > Exactly. Sorry for not being clear. I didn't mean use EFL++ for the > > elm_web, but for the WebKit backend for EFL. There's no reason to use > > the C EFL API by C++ code, IMO. > > oh - then i don't know .. but i suspect the code is already done and using > efl's c interface inside the c++ code as that is working today already. > > -- > - Codito, ergo sum - "I code, therefore I am" -- > The Rasterman (Carsten Haitzler)ras...@rasterman.com > > > > -- > Open source business process management suite built on Java and Eclipse > Turn processes into business applications with Bonita BPM Community Edition > Quickly connect people, data, and systems into organized workflows > Winner of BOSSIE, CODIE, OW2 and Gartner awards > http://p.sf.net/sfu/Bonitasoft > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [webkit-efl] Stop to maintain EFL WK1 port
On Wed, 25 Jun 2014 12:44:19 -0300 Felipe Magno de Almeida said: > On Sat, Jun 21, 2014 at 1:20 AM, Cedric BAIL wrote: > > On Jun 21, 2014 2:26 AM, "Carsten Haitzler" wrote: > >> On Fri, 20 Jun 2014 21:25:54 -0300 Felipe Magno de Almeida > >> said: > >> > On Fri, Jun 20, 2014 at 9:07 PM, Carsten Haitzler > >> > wrote: > >> > > On Fri, 20 Jun 2014 15:02:37 -0300 Felipe Magno de Almeida > >> > > said: > > [snip] > > >> > I think it would make the port easier to mantain. It would give RAII, > >> > STL-compatibility, easier callback support with lambda-support and a > >> > value-based API. But that's just my opinion. > >> > >> elm web has a c api. will always have one. thus we then would have to > > write a c+ > >> + elm web by hand AND a c+eo one. no. use eo to write one and efl++ > > exposes elm > >> web. webkit api is internal then and thats how it should be. > > > > I think Felipe was referring to the internal of WebKit talking to efl which > > is already in c++ and would likely benefit from using the c++ with no > > penalty. > > Exactly. Sorry for not being clear. I didn't mean use EFL++ for the > elm_web, but for the WebKit backend for EFL. There's no reason to use > the C EFL API by C++ code, IMO. oh - then i don't know .. but i suspect the code is already done and using efl's c interface inside the c++ code as that is working today already. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [webkit-efl] Stop to maintain EFL WK1 port
On Sat, Jun 21, 2014 at 1:20 AM, Cedric BAIL wrote: > On Jun 21, 2014 2:26 AM, "Carsten Haitzler" wrote: >> On Fri, 20 Jun 2014 21:25:54 -0300 Felipe Magno de Almeida >> said: >> > On Fri, Jun 20, 2014 at 9:07 PM, Carsten Haitzler >> > wrote: >> > > On Fri, 20 Jun 2014 15:02:37 -0300 Felipe Magno de Almeida >> > > said: [snip] >> > I think it would make the port easier to mantain. It would give RAII, >> > STL-compatibility, easier callback support with lambda-support and a >> > value-based API. But that's just my opinion. >> >> elm web has a c api. will always have one. thus we then would have to > write a c+ >> + elm web by hand AND a c+eo one. no. use eo to write one and efl++ > exposes elm >> web. webkit api is internal then and thats how it should be. > > I think Felipe was referring to the internal of WebKit talking to efl which > is already in c++ and would likely benefit from using the c++ with no > penalty. Exactly. Sorry for not being clear. I didn't mean use EFL++ for the elm_web, but for the WebKit backend for EFL. There's no reason to use the C EFL API by C++ code, IMO. Regards, -- Felipe Magno de Almeida -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [webkit-efl] Stop to maintain EFL WK1 port
On Jun 21, 2014 2:26 AM, "Carsten Haitzler" wrote: > > On Fri, 20 Jun 2014 21:25:54 -0300 Felipe Magno de Almeida > said: > > > On Fri, Jun 20, 2014 at 9:07 PM, Carsten Haitzler > > wrote: > > > On Fri, 20 Jun 2014 15:02:37 -0300 Felipe Magno de Almeida > > > said: > > > > > >> Em 19/06/2014 23:59, "Carsten Haitzler" escreveu: > > >> > > > >> > just webkit2 will do. if we can migrate to it for elm_web completely then > > >> > that'd be awesome. > > >> > > >> And maybe use EFL++ too? :-) > > > > > > no - as that would mean making elementary core pull in all the efl++ > > > bindings, forcing everyone to link to the efl++ binding libs regardless. > > > > There's no linking involved. Everything is header-only, even the > > generated files. > > > > > also i see no value here. we are using webkit2. with webkit1, the api we > > > used was a C api exposed by webkit (the webkit efl api). i don't know what > > > the webkit2 api looks like, but all we need to do is drive the api exposed > > > to control it and use the efl glue already in webkit2 to get it to display > > > and work in a widget. we don't need efl++ for that. it's a bit of a > > > contortion. :) > > > > I think it would make the port easier to mantain. It would give RAII, > > STL-compatibility, easier callback support with lambda-support and a > > value-based API. But that's just my opinion. > > elm web has a c api. will always have one. thus we then would have to write a c+ > + elm web by hand AND a c+eo one. no. use eo to write one and efl++ exposes elm > web. webkit api is internal then and thats how it should be. I think Felipe was referring to the internal of WebKit talking to efl which is already in c++ and would likely benefit from using the c++ with no penalty. > > > -- > - Codito, ergo sum - "I code, therefore I am" -- > The Rasterman (Carsten Haitzler)ras...@rasterman.com > > > -- > HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions > Find What Matters Most in Your Big Data with HPCC Systems > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. > Leverages Graph Analysis for Fast Processing & Easy Data Exploration > http://p.sf.net/sfu/hpccsystems > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [webkit-efl] Stop to maintain EFL WK1 port
On Fri, 20 Jun 2014 21:25:54 -0300 Felipe Magno de Almeida said: > On Fri, Jun 20, 2014 at 9:07 PM, Carsten Haitzler > wrote: > > On Fri, 20 Jun 2014 15:02:37 -0300 Felipe Magno de Almeida > > said: > > > >> Em 19/06/2014 23:59, "Carsten Haitzler" escreveu: > >> > > >> > just webkit2 will do. if we can migrate to it for elm_web completely then > >> > that'd be awesome. > >> > >> And maybe use EFL++ too? :-) > > > > no - as that would mean making elementary core pull in all the efl++ > > bindings, forcing everyone to link to the efl++ binding libs regardless. > > There's no linking involved. Everything is header-only, even the > generated files. > > > also i see no value here. we are using webkit2. with webkit1, the api we > > used was a C api exposed by webkit (the webkit efl api). i don't know what > > the webkit2 api looks like, but all we need to do is drive the api exposed > > to control it and use the efl glue already in webkit2 to get it to display > > and work in a widget. we don't need efl++ for that. it's a bit of a > > contortion. :) > > I think it would make the port easier to mantain. It would give RAII, > STL-compatibility, easier callback support with lambda-support and a > value-based API. But that's just my opinion. elm web has a c api. will always have one. thus we then would have to write a c+ + elm web by hand AND a c+eo one. no. use eo to write one and efl++ exposes elm web. webkit api is internal then and thats how it should be. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [webkit-efl] Stop to maintain EFL WK1 port
On Fri, Jun 20, 2014 at 9:07 PM, Carsten Haitzler wrote: > On Fri, 20 Jun 2014 15:02:37 -0300 Felipe Magno de Almeida > said: > >> Em 19/06/2014 23:59, "Carsten Haitzler" escreveu: >> > >> > just webkit2 will do. if we can migrate to it for elm_web completely then >> > that'd be awesome. >> >> And maybe use EFL++ too? :-) > > no - as that would mean making elementary core pull in all the efl++ bindings, > forcing everyone to link to the efl++ binding libs regardless. There's no linking involved. Everything is header-only, even the generated files. > also i see no value here. we are using webkit2. with webkit1, the api we > used was a C api exposed by webkit (the webkit efl api). i don't know what > the webkit2 api looks like, but all we need to do is drive the api exposed > to control it and use the efl glue already in webkit2 to get it to display and > work in a widget. we don't need efl++ for that. it's a bit of a contortion. :) I think it would make the port easier to mantain. It would give RAII, STL-compatibility, easier callback support with lambda-support and a value-based API. But that's just my opinion. > - Codito, ergo sum - "I code, therefore I am" -- > The Rasterman (Carsten Haitzler)ras...@rasterman.com Regards, -- Felipe Magno de Almeida -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [webkit-efl] Stop to maintain EFL WK1 port
On Fri, 20 Jun 2014 15:02:37 -0300 Felipe Magno de Almeida said: > Em 19/06/2014 23:59, "Carsten Haitzler" escreveu: > > > > just webkit2 will do. if we can migrate to it for elm_web completely then > > that'd be awesome. > > And maybe use EFL++ too? :-) no - as that would mean making elementary core pull in all the efl++ bindings, forcing everyone to link to the efl++ binding libs regardless. also i see no value here. we are using webkit2. with webkit1, the api we used was a C api exposed by webkit (the webkit efl api). i don't know what the webkit2 api looks like, but all we need to do is drive the api exposed to control it and use the efl glue already in webkit2 to get it to display and work in a widget. we don't need efl++ for that. it's a bit of a contortion. :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [webkit-efl] Stop to maintain EFL WK1 port
Em 19/06/2014 23:59, "Carsten Haitzler" escreveu: > > just webkit2 will do. if we can migrate to it for elm_web completely then > that'd be awesome. And maybe use EFL++ too? :-) > -- > - Codito, ergo sum - "I code, therefore I am" -- > The Rasterman (Carsten Haitzler)ras...@rasterman.com -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [webkit-efl] Stop to maintain EFL WK1 port
On Mon, 16 Jun 2014 18:50:58 +0900 ryuan Choi said: > I cc'd efl mailing list for someone who may use EFL WK1 port. > > Unfortunately, I agree with you. > Nowadays, we don't have enough man power to maintain two ports. > > If nobody volunteer, I will also support it. just webkit2 will do. if we can migrate to it for elm_web completely then that'd be awesome. > Best Regards, > Ryuan Choi > > > > 2014-06-14 23:50 GMT+09:00 Laszlo Gombos : > > > Hi Gyuyoung, > > > > Thanks for initiating this discussion. > > > > I support the removal of EFL WK1 port from WebKit trunk and I think this > > should help maintaining EFL WK2 port. > > > > Best Regards, > > Laszlo > > > > > > On Sat, Jun 14, 2014 at 5:52 AM, Gyuyoung Kim > > wrote: > > > >> Hello WebKit-EFL folks, > >> > >> I would like to talk about our old issue - "How long will we support EFL > >> WK1 port ?" > >> > >> We had used EFL WK1 port for some projects internally as well as elm-web > >> as one of elementary's sub libraries. However, now we don't use EFL WK1 > >> port anymore. Besides, AFAIK, elm-web is gonna use EFL WK2. > >> > >> Thus I'd like to stop to maintain the EFL WK1 port. > >> > >> If anyone objects to remove EFL WK1 port, please let me know. > >> > >> Thanks, > >> Gyuyoung. > >> > >> ___ > >> webkit-efl mailing list > >> webkit-...@lists.webkit.org > >> https://lists.webkit.org/mailman/listinfo/webkit-efl > >> > >> > > > > ___ > > webkit-efl mailing list > > webkit-...@lists.webkit.org > > https://lists.webkit.org/mailman/listinfo/webkit-efl > > > > > -- > HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions > Find What Matters Most in Your Big Data with HPCC Systems > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. > Leverages Graph Analysis for Fast Processing & Easy Data Exploration > http://p.sf.net/sfu/hpccsystems > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [webkit-efl] Stop to maintain EFL WK1 port
Thanks for initiating this topic. I don't know how other EFL folks think but from my side it is ok to remove it. If it is known not to be used that much and if there is no volunteer to maintain it, it could be removed from the trunk to reduce unnecessary maintain costs. Thanks. Daniel Juyung Seo (SeoZ) On Mon, Jun 16, 2014 at 10:16 PM, Gyuyoung Kim wrote: > Thank you Laszlo and Ryuan, If there isn't any objection until end of this > weekend, l will remove EFL WK1 port as GTK WK1 port. > > Gyuyoung. > > > On Mon, Jun 16, 2014 at 6:50 PM, ryuan Choi wrote: > >> I cc'd efl mailing list for someone who may use EFL WK1 port. >> >> Unfortunately, I agree with you. >> Nowadays, we don't have enough man power to maintain two ports. >> >> If nobody volunteer, I will also support it. >> >> Best Regards, >> Ryuan Choi >> >> >> >> 2014-06-14 23:50 GMT+09:00 Laszlo Gombos : >> >> Hi Gyuyoung, >>> >>> Thanks for initiating this discussion. >>> >>> I support the removal of EFL WK1 port from WebKit trunk and I think this >>> should help maintaining EFL WK2 port. >>> >>> Best Regards, >>> Laszlo >>> >>> >>> On Sat, Jun 14, 2014 at 5:52 AM, Gyuyoung Kim >>> wrote: >>> Hello WebKit-EFL folks, I would like to talk about our old issue - "How long will we support EFL WK1 port ?" We had used EFL WK1 port for some projects internally as well as elm-web as one of elementary's sub libraries. However, now we don't use EFL WK1 port anymore. Besides, AFAIK, elm-web is gonna use EFL WK2. Thus I'd like to stop to maintain the EFL WK1 port. If anyone objects to remove EFL WK1 port, please let me know. Thanks, Gyuyoung. ___ webkit-efl mailing list webkit-...@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-efl >>> >>> ___ >>> webkit-efl mailing list >>> webkit-...@lists.webkit.org >>> https://lists.webkit.org/mailman/listinfo/webkit-efl >>> >>> >> > > ___ > webkit-efl mailing list > webkit-...@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-efl > > -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [webkit-efl] Stop to maintain EFL WK1 port
I cc'd efl mailing list for someone who may use EFL WK1 port. Unfortunately, I agree with you. Nowadays, we don't have enough man power to maintain two ports. If nobody volunteer, I will also support it. Best Regards, Ryuan Choi 2014-06-14 23:50 GMT+09:00 Laszlo Gombos : > Hi Gyuyoung, > > Thanks for initiating this discussion. > > I support the removal of EFL WK1 port from WebKit trunk and I think this > should help maintaining EFL WK2 port. > > Best Regards, > Laszlo > > > On Sat, Jun 14, 2014 at 5:52 AM, Gyuyoung Kim > wrote: > >> Hello WebKit-EFL folks, >> >> I would like to talk about our old issue - "How long will we support EFL >> WK1 port ?" >> >> We had used EFL WK1 port for some projects internally as well as elm-web >> as one of elementary's sub libraries. However, now we don't use EFL WK1 >> port anymore. Besides, AFAIK, elm-web is gonna use EFL WK2. >> >> Thus I'd like to stop to maintain the EFL WK1 port. >> >> If anyone objects to remove EFL WK1 port, please let me know. >> >> Thanks, >> Gyuyoung. >> >> ___ >> webkit-efl mailing list >> webkit-...@lists.webkit.org >> https://lists.webkit.org/mailman/listinfo/webkit-efl >> >> > > ___ > webkit-efl mailing list > webkit-...@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-efl > > -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Webkit EFL
On Thu, Dec 19, 2013 at 6:26 AM, Igor Murzov wrote: > I've got another compilation failure due to incorrect freetype > include path: > > Building CXX object > Source/WebCore/CMakeFiles/WebCore.dir/platform/graphics/freetype/FontPlatformDataFreeType.cpp.o > /tmp/tgz/webkit-efl/Source/WebCore/platform/graphics/freetype/FontPlatformDataFreeType.cpp:32:22: > fatal error: tttables.h: No such file or directory > #include > > > The missing file is actually present in /usr/include/freetype2/freetype/, > but compiler failed to find it. pkg-config prints the following path: > > $ pkg-config --cflags freetype2 > -I/usr/include/freetype2 > > so I had to edit some source files in WebCore to make it compile. > > Looks like someone should put this into webkit too https://git.enlightenment.org/core/efl.git/commit/?id=c12ac143c68bf193e5154ca1e0e6471d9a2d7fb2 > -- Igor > > > On Wed, 18 Dec 2013 20:18:42 +0900 > ryuan Choi wrote: > >> Interesting, PNGImageDecoder.cpp already checked the libpng version but >> checked whether it is bigger than 1.5 >> >> >> >> 2013/12/18 Cedric BAIL >> >> > On Wed, Dec 18, 2013 at 5:07 PM, Igor Murzov >> > wrote: >> > > Compilation fails for me with the following error: >> > > >> > > [ 13%] Building CXX object >> > Source/WebCore/CMakeFiles/WebCore.dir/platform/image-decoders/png/PNGImageDecoder.cpp.o >> > > >> > /tmp/tgz/webkit-efl/Source/WebCore/platform/image-decoders/png/PNGImageDecoder.cpp: >> > In member function 'void WebCore::PNGImageDecoder::headerAvailable()': >> > > >> > /tmp/tgz/webkit-efl/Source/WebCore/platform/image-decoders/png/PNGImageDecoder.cpp:393:70: >> > error: 'png_struct_def::buffer_size' is deprecated (declared at >> > /usr/include/libpng14/png.h:1337) [-Werror=deprecated-declarations] >> > > m_reader->setReadOffset(m_reader->currentBufferSize() - >> > png->buffer_size); >> > > ^ >> > > >> > /tmp/tgz/webkit-efl/Source/WebCore/platform/image-decoders/png/PNGImageDecoder.cpp:393:70: >> > error: 'png_struct_def::buffer_size' is deprecated (declared at >> > /usr/include/libpng14/png.h:1337) [-Werror=deprecated-declarations] >> > > >> > /tmp/tgz/webkit-efl/Source/WebCore/platform/image-decoders/png/PNGImageDecoder.cpp:394:14: >> > error: 'png_struct_def::buffer_size' is deprecated (declared at >> > /usr/include/libpng14/png.h:1337) [-Werror=deprecated-declarations] >> > > png->buffer_size = 0; >> > > ^ >> > > >> > /tmp/tgz/webkit-efl/Source/WebCore/platform/image-decoders/png/PNGImageDecoder.cpp:394:14: >> > error: 'png_struct_def::buffer_size' is deprecated (declared at >> > /usr/include/libpng14/png.h:1337) [-Werror=deprecated-declarations] >> > > cc1plus: all warnings being treated as errors >> > > make[2]: *** >> > [Source/WebCore/CMakeFiles/WebCore.dir/platform/image-decoders/png/PNGImageDecoder.cpp.o] >> > Error 1 >> > > make[1]: *** [Source/WebCore/CMakeFiles/WebCore.dir/all] Error 2 >> > > make: *** [all] Error 2 >> > > >> > > >> > > My system is Slackware 14.1 with gcc-4.8.2, libpng-1.4.12, >> > > efl-1.8.2. >> > >> > I am guessing that your libpng is to old (not sure), but webkit efl is >> > really something that require all the latest technology. >> > -- >> > Cedric BAIL > > -- > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Webkit EFL
I've got another compilation failure due to incorrect freetype include path: Building CXX object Source/WebCore/CMakeFiles/WebCore.dir/platform/graphics/freetype/FontPlatformDataFreeType.cpp.o /tmp/tgz/webkit-efl/Source/WebCore/platform/graphics/freetype/FontPlatformDataFreeType.cpp:32:22: fatal error: tttables.h: No such file or directory #include The missing file is actually present in /usr/include/freetype2/freetype/, but compiler failed to find it. pkg-config prints the following path: $ pkg-config --cflags freetype2 -I/usr/include/freetype2 so I had to edit some source files in WebCore to make it compile. -- Igor On Wed, 18 Dec 2013 20:18:42 +0900 ryuan Choi wrote: > Interesting, PNGImageDecoder.cpp already checked the libpng version but > checked whether it is bigger than 1.5 > > > > 2013/12/18 Cedric BAIL > > > On Wed, Dec 18, 2013 at 5:07 PM, Igor Murzov > > wrote: > > > Compilation fails for me with the following error: > > > > > > [ 13%] Building CXX object > > Source/WebCore/CMakeFiles/WebCore.dir/platform/image-decoders/png/PNGImageDecoder.cpp.o > > > > > /tmp/tgz/webkit-efl/Source/WebCore/platform/image-decoders/png/PNGImageDecoder.cpp: > > In member function 'void WebCore::PNGImageDecoder::headerAvailable()': > > > > > /tmp/tgz/webkit-efl/Source/WebCore/platform/image-decoders/png/PNGImageDecoder.cpp:393:70: > > error: 'png_struct_def::buffer_size' is deprecated (declared at > > /usr/include/libpng14/png.h:1337) [-Werror=deprecated-declarations] > > > m_reader->setReadOffset(m_reader->currentBufferSize() - > > png->buffer_size); > > > ^ > > > > > /tmp/tgz/webkit-efl/Source/WebCore/platform/image-decoders/png/PNGImageDecoder.cpp:393:70: > > error: 'png_struct_def::buffer_size' is deprecated (declared at > > /usr/include/libpng14/png.h:1337) [-Werror=deprecated-declarations] > > > > > /tmp/tgz/webkit-efl/Source/WebCore/platform/image-decoders/png/PNGImageDecoder.cpp:394:14: > > error: 'png_struct_def::buffer_size' is deprecated (declared at > > /usr/include/libpng14/png.h:1337) [-Werror=deprecated-declarations] > > > png->buffer_size = 0; > > > ^ > > > > > /tmp/tgz/webkit-efl/Source/WebCore/platform/image-decoders/png/PNGImageDecoder.cpp:394:14: > > error: 'png_struct_def::buffer_size' is deprecated (declared at > > /usr/include/libpng14/png.h:1337) [-Werror=deprecated-declarations] > > > cc1plus: all warnings being treated as errors > > > make[2]: *** > > [Source/WebCore/CMakeFiles/WebCore.dir/platform/image-decoders/png/PNGImageDecoder.cpp.o] > > Error 1 > > > make[1]: *** [Source/WebCore/CMakeFiles/WebCore.dir/all] Error 2 > > > make: *** [all] Error 2 > > > > > > > > > My system is Slackware 14.1 with gcc-4.8.2, libpng-1.4.12, > > > efl-1.8.2. > > > > I am guessing that your libpng is to old (not sure), but webkit efl is > > really something that require all the latest technology. > > -- > > Cedric BAIL -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Webkit EFL
Interesting, PNGImageDecoder.cpp already checked the libpng version but checked whether it is bigger than 1.5 2013/12/18 Cedric BAIL > On Wed, Dec 18, 2013 at 5:07 PM, Igor Murzov > wrote: > > Compilation fails for me with the following error: > > > > [ 13%] Building CXX object > Source/WebCore/CMakeFiles/WebCore.dir/platform/image-decoders/png/PNGImageDecoder.cpp.o > > > /tmp/tgz/webkit-efl/Source/WebCore/platform/image-decoders/png/PNGImageDecoder.cpp: > In member function 'void WebCore::PNGImageDecoder::headerAvailable()': > > > /tmp/tgz/webkit-efl/Source/WebCore/platform/image-decoders/png/PNGImageDecoder.cpp:393:70: > error: 'png_struct_def::buffer_size' is deprecated (declared at > /usr/include/libpng14/png.h:1337) [-Werror=deprecated-declarations] > > m_reader->setReadOffset(m_reader->currentBufferSize() - > png->buffer_size); > > ^ > > > /tmp/tgz/webkit-efl/Source/WebCore/platform/image-decoders/png/PNGImageDecoder.cpp:393:70: > error: 'png_struct_def::buffer_size' is deprecated (declared at > /usr/include/libpng14/png.h:1337) [-Werror=deprecated-declarations] > > > /tmp/tgz/webkit-efl/Source/WebCore/platform/image-decoders/png/PNGImageDecoder.cpp:394:14: > error: 'png_struct_def::buffer_size' is deprecated (declared at > /usr/include/libpng14/png.h:1337) [-Werror=deprecated-declarations] > > png->buffer_size = 0; > > ^ > > > /tmp/tgz/webkit-efl/Source/WebCore/platform/image-decoders/png/PNGImageDecoder.cpp:394:14: > error: 'png_struct_def::buffer_size' is deprecated (declared at > /usr/include/libpng14/png.h:1337) [-Werror=deprecated-declarations] > > cc1plus: all warnings being treated as errors > > make[2]: *** > [Source/WebCore/CMakeFiles/WebCore.dir/platform/image-decoders/png/PNGImageDecoder.cpp.o] > Error 1 > > make[1]: *** [Source/WebCore/CMakeFiles/WebCore.dir/all] Error 2 > > make: *** [all] Error 2 > > > > > > My system is Slackware 14.1 with gcc-4.8.2, libpng-1.4.12, > > efl-1.8.2. > > I am guessing that your libpng is to old (not sure), but webkit efl is > really something that require all the latest technology. > -- > Cedric BAIL > > > -- > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics > Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Webkit EFL
On Wed, Dec 18, 2013 at 5:07 PM, Igor Murzov wrote: > Compilation fails for me with the following error: > > [ 13%] Building CXX object > Source/WebCore/CMakeFiles/WebCore.dir/platform/image-decoders/png/PNGImageDecoder.cpp.o > /tmp/tgz/webkit-efl/Source/WebCore/platform/image-decoders/png/PNGImageDecoder.cpp: > In member function 'void WebCore::PNGImageDecoder::headerAvailable()': > /tmp/tgz/webkit-efl/Source/WebCore/platform/image-decoders/png/PNGImageDecoder.cpp:393:70: > error: 'png_struct_def::buffer_size' is deprecated (declared at > /usr/include/libpng14/png.h:1337) [-Werror=deprecated-declarations] > m_reader->setReadOffset(m_reader->currentBufferSize() - > png->buffer_size); > ^ > /tmp/tgz/webkit-efl/Source/WebCore/platform/image-decoders/png/PNGImageDecoder.cpp:393:70: > error: 'png_struct_def::buffer_size' is deprecated (declared at > /usr/include/libpng14/png.h:1337) [-Werror=deprecated-declarations] > /tmp/tgz/webkit-efl/Source/WebCore/platform/image-decoders/png/PNGImageDecoder.cpp:394:14: > error: 'png_struct_def::buffer_size' is deprecated (declared at > /usr/include/libpng14/png.h:1337) [-Werror=deprecated-declarations] > png->buffer_size = 0; > ^ > /tmp/tgz/webkit-efl/Source/WebCore/platform/image-decoders/png/PNGImageDecoder.cpp:394:14: > error: 'png_struct_def::buffer_size' is deprecated (declared at > /usr/include/libpng14/png.h:1337) [-Werror=deprecated-declarations] > cc1plus: all warnings being treated as errors > make[2]: *** > [Source/WebCore/CMakeFiles/WebCore.dir/platform/image-decoders/png/PNGImageDecoder.cpp.o] > Error 1 > make[1]: *** [Source/WebCore/CMakeFiles/WebCore.dir/all] Error 2 > make: *** [all] Error 2 > > > My system is Slackware 14.1 with gcc-4.8.2, libpng-1.4.12, > efl-1.8.2. I am guessing that your libpng is to old (not sure), but webkit efl is really something that require all the latest technology. -- Cedric BAIL -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Webkit EFL
> Date: Wed, 18 Dec 2013 12:23:30 +0400 > From: intergalactic.anonym...@gmail.com > To: enlightenment-devel@lists.sourceforge.net > Subject: Re: [E-devel] Webkit EFL > > Compilation fails for me with the following error: > > [ 13%] Building CXX object > Source/WebCore/CMakeFiles/WebCore.dir/platform/image-decoders/png/PNGImageDecoder.cpp.o > /tmp/tgz/webkit-efl/Source/WebCore/platform/image-decoders/png/PNGImageDecoder.cpp: > In member function 'void WebCore::PNGImageDecoder::headerAvailable()': > /tmp/tgz/webkit-efl/Source/WebCore/platform/image-decoders/png/PNGImageDecoder.cpp:393:70: > error: 'png_struct_def::buffer_size' is deprecated (declared at > /usr/include/libpng14/png.h:1337) [-Werror=deprecated-declarations] > m_reader->setReadOffset(m_reader->currentBufferSize() - png->buffer_size); > ^ > /tmp/tgz/webkit-efl/Source/WebCore/platform/image-decoders/png/PNGImageDecoder.cpp:393:70: > error: 'png_struct_def::buffer_size' is deprecated (declared at > /usr/include/libpng14/png.h:1337) [-Werror=deprecated-declarations] > /tmp/tgz/webkit-efl/Source/WebCore/platform/image-decoders/png/PNGImageDecoder.cpp:394:14: > error: 'png_struct_def::buffer_size' is deprecated (declared at > /usr/include/libpng14/png.h:1337) [-Werror=deprecated-declarations] > png->buffer_size = 0; > ^ > /tmp/tgz/webkit-efl/Source/WebCore/platform/image-decoders/png/PNGImageDecoder.cpp:394:14: > error: 'png_struct_def::buffer_size' is deprecated (declared at > /usr/include/libpng14/png.h:1337) [-Werror=deprecated-declarations] > cc1plus: all warnings being treated as errors > make[2]: *** > [Source/WebCore/CMakeFiles/WebCore.dir/platform/image-decoders/png/PNGImageDecoder.cpp.o] > Error 1 > make[1]: *** [Source/WebCore/CMakeFiles/WebCore.dir/all] Error 2 > make: *** [all] Error 2 > > > My system is Slackware 14.1 with gcc-4.8.2, libpng-1.4.12, > efl-1.8.2. > > > -- Igor Add "-Wno-deprecated-declarations" to your CXXFLAGS. I'm thinking this is pretty much a requirement if you have an up to date system, webkit-efl seems to be very slow to adapt to upstream changes in libs; I've had similar issues with glib and libsoup. There's really no downside to using it, it just allows you to actually use deprecated, but still present, features. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Webkit EFL
Compilation fails for me with the following error: [ 13%] Building CXX object Source/WebCore/CMakeFiles/WebCore.dir/platform/image-decoders/png/PNGImageDecoder.cpp.o /tmp/tgz/webkit-efl/Source/WebCore/platform/image-decoders/png/PNGImageDecoder.cpp: In member function 'void WebCore::PNGImageDecoder::headerAvailable()': /tmp/tgz/webkit-efl/Source/WebCore/platform/image-decoders/png/PNGImageDecoder.cpp:393:70: error: 'png_struct_def::buffer_size' is deprecated (declared at /usr/include/libpng14/png.h:1337) [-Werror=deprecated-declarations] m_reader->setReadOffset(m_reader->currentBufferSize() - png->buffer_size); ^ /tmp/tgz/webkit-efl/Source/WebCore/platform/image-decoders/png/PNGImageDecoder.cpp:393:70: error: 'png_struct_def::buffer_size' is deprecated (declared at /usr/include/libpng14/png.h:1337) [-Werror=deprecated-declarations] /tmp/tgz/webkit-efl/Source/WebCore/platform/image-decoders/png/PNGImageDecoder.cpp:394:14: error: 'png_struct_def::buffer_size' is deprecated (declared at /usr/include/libpng14/png.h:1337) [-Werror=deprecated-declarations] png->buffer_size = 0; ^ /tmp/tgz/webkit-efl/Source/WebCore/platform/image-decoders/png/PNGImageDecoder.cpp:394:14: error: 'png_struct_def::buffer_size' is deprecated (declared at /usr/include/libpng14/png.h:1337) [-Werror=deprecated-declarations] cc1plus: all warnings being treated as errors make[2]: *** [Source/WebCore/CMakeFiles/WebCore.dir/platform/image-decoders/png/PNGImageDecoder.cpp.o] Error 1 make[1]: *** [Source/WebCore/CMakeFiles/WebCore.dir/all] Error 2 make: *** [all] Error 2 My system is Slackware 14.1 with gcc-4.8.2, libpng-1.4.12, efl-1.8.2. -- Igor On Thu, 12 Dec 2013 14:39:11 +0900 Cedric BAIL wrote: > Hello, > > Thanks to the help of Ryuan Choi, we can announce today the release of > a recent Webkit EFL snapshot. It is based on svn r159807. You can this > tarball here (as it was a little bit big, I did go with xz): > http://download.enlightenment.org/rel/libs/webkit-efl/webkit-efl-159807.tar.xz > . > > To build it, you need EFL 1.8 and libsoup 2.42 at least. Then > something like that will do : > mkdir build && cd build > cmake .. -DPORT=Efl -DENABLE_WEB_AUDIO=Off -DENABLE_VIDEO=Off > -DENABLE_VIDEO_TRACK=Off -DENABLE_ACCESSIBILITY=Off > -DENABLE_BATTERY_STATUS=Off -DCMAKE_INSTALL_PREFIX=/usr/local > make -j 4 > > I have tested it with elm web and it work quite well for me. I hope it > will be useful for others. Just be aware that if you build it, you > need around 4G of ram for the linker. This means it can only be build > on 64bits system. Cross compilation is required for 32bits system. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Webkit EFL
Compilation fails for me with the following error: [ 13%] Building CXX object Source/WebCore/CMakeFiles/WebCore.dir/platform/image-decoders/png/PNGImageDecoder.cpp.o /tmp/tgz/webkit-efl/Source/WebCore/platform/image-decoders/png/PNGImageDecoder.cpp: In member function 'void WebCore::PNGImageDecoder::headerAvailable()': /tmp/tgz/webkit-efl/Source/WebCore/platform/image-decoders/png/PNGImageDecoder.cpp:393:70: error: 'png_struct_def::buffer_size' is deprecated (declared at /usr/include/libpng14/png.h:1337) [-Werror=deprecated-declarations] m_reader->setReadOffset(m_reader->currentBufferSize() - png->buffer_size); ^ /tmp/tgz/webkit-efl/Source/WebCore/platform/image-decoders/png/PNGImageDecoder.cpp:393:70: error: 'png_struct_def::buffer_size' is deprecated (declared at /usr/include/libpng14/png.h:1337) [-Werror=deprecated-declarations] /tmp/tgz/webkit-efl/Source/WebCore/platform/image-decoders/png/PNGImageDecoder.cpp:394:14: error: 'png_struct_def::buffer_size' is deprecated (declared at /usr/include/libpng14/png.h:1337) [-Werror=deprecated-declarations] png->buffer_size = 0; ^ /tmp/tgz/webkit-efl/Source/WebCore/platform/image-decoders/png/PNGImageDecoder.cpp:394:14: error: 'png_struct_def::buffer_size' is deprecated (declared at /usr/include/libpng14/png.h:1337) [-Werror=deprecated-declarations] cc1plus: all warnings being treated as errors make[2]: *** [Source/WebCore/CMakeFiles/WebCore.dir/platform/image-decoders/png/PNGImageDecoder.cpp.o] Error 1 make[1]: *** [Source/WebCore/CMakeFiles/WebCore.dir/all] Error 2 make: *** [all] Error 2 My system is Slackware 14.1 with gcc-4.8.2, libpng-1.4.12, efl-1.8.2. -- Igor On Thu, 12 Dec 2013 14:39:11 +0900 Cedric BAIL wrote: > Hello, > > Thanks to the help of Ryuan Choi, we can announce today the release of > a recent Webkit EFL snapshot. It is based on svn r159807. You can this > tarball here (as it was a little bit big, I did go with xz): > http://download.enlightenment.org/rel/libs/webkit-efl/webkit-efl-159807.tar.xz > . > > To build it, you need EFL 1.8 and libsoup 2.42 at least. Then > something like that will do : > mkdir build && cd build > cmake .. -DPORT=Efl -DENABLE_WEB_AUDIO=Off -DENABLE_VIDEO=Off > -DENABLE_VIDEO_TRACK=Off -DENABLE_ACCESSIBILITY=Off > -DENABLE_BATTERY_STATUS=Off -DCMAKE_INSTALL_PREFIX=/usr/local > make -j 4 > > I have tested it with elm web and it work quite well for me. I hope it > will be useful for others. Just be aware that if you build it, you > need around 4G of ram for the linker. This means it can only be build > on 64bits system. Cross compilation is required for 32bits system. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Webkit EFL
This is great, glad to see a release for this. ~Jeff Hoogland Bodhi Linux - http://www.bodhilinux.com/ On Dec 12, 2013 7:28 AM, "Tom Hacohen" wrote: > On 12/12/13 13:12, ryuan Choi wrote: > > No, you can enable them but you need to install some more additional > > packages (source folders). > > > > For Accessibility, atk 2.10 is required. ( > > http://ftp.gnome.org/pub/GNOME/sources/atk/2.10/atk-2.10.0.tar.xz) > > For VIDEO, VIDEO_TRACK and WEB_AUDIO, gstreamer and series 1.2.1 are > > required ( > > - gstreamer : > > http://gstreamer.freedesktop.org/src/gstreamer/gstreamer-1.2.1.tar.xz > > - gst-plugins-base : > > > http://gstreamer.freedesktop.org/src/gst-plugins-base/gst-plugins-base-1.2.1.tar.xz > > - gst-plugins-good : > > > http://gstreamer.freedesktop.org/src/gst-plugins-good/gst-plugins-good-1.2.1.tar.xz > > - gst-plugins-bad : > > > http://gstreamer.freedesktop.org/src/gst-plugins-bad/gst-plugins-bad-1.2.1.tar.xz > > - gst-libav : > > http://gstreamer.freedesktop.org/src/gst-libav/gst-libav-1.2.1.tar.xz > > ) > > For Battery Status, e_dbus is required. > > OK, so it does work, that's what I was worried about. :) > > -- > Tom. > > > > -- > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics > Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Webkit EFL
On 12/12/13 13:12, ryuan Choi wrote: > No, you can enable them but you need to install some more additional > packages (source folders). > > For Accessibility, atk 2.10 is required. ( > http://ftp.gnome.org/pub/GNOME/sources/atk/2.10/atk-2.10.0.tar.xz) > For VIDEO, VIDEO_TRACK and WEB_AUDIO, gstreamer and series 1.2.1 are > required ( > - gstreamer : > http://gstreamer.freedesktop.org/src/gstreamer/gstreamer-1.2.1.tar.xz > - gst-plugins-base : > http://gstreamer.freedesktop.org/src/gst-plugins-base/gst-plugins-base-1.2.1.tar.xz > - gst-plugins-good : > http://gstreamer.freedesktop.org/src/gst-plugins-good/gst-plugins-good-1.2.1.tar.xz > - gst-plugins-bad : > http://gstreamer.freedesktop.org/src/gst-plugins-bad/gst-plugins-bad-1.2.1.tar.xz > - gst-libav : > http://gstreamer.freedesktop.org/src/gst-libav/gst-libav-1.2.1.tar.xz > ) > For Battery Status, e_dbus is required. OK, so it does work, that's what I was worried about. :) -- Tom. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Webkit EFL
No, you can enable them but you need to install some more additional packages (source folders). For Accessibility, atk 2.10 is required. ( http://ftp.gnome.org/pub/GNOME/sources/atk/2.10/atk-2.10.0.tar.xz) For VIDEO, VIDEO_TRACK and WEB_AUDIO, gstreamer and series 1.2.1 are required ( - gstreamer : http://gstreamer.freedesktop.org/src/gstreamer/gstreamer-1.2.1.tar.xz - gst-plugins-base : http://gstreamer.freedesktop.org/src/gst-plugins-base/gst-plugins-base-1.2.1.tar.xz - gst-plugins-good : http://gstreamer.freedesktop.org/src/gst-plugins-good/gst-plugins-good-1.2.1.tar.xz - gst-plugins-bad : http://gstreamer.freedesktop.org/src/gst-plugins-bad/gst-plugins-bad-1.2.1.tar.xz - gst-libav : http://gstreamer.freedesktop.org/src/gst-libav/gst-libav-1.2.1.tar.xz ) For Battery Status, e_dbus is required. Best Regards, Ryuan Choi 2013/12/12 Tom Hacohen > On 12/12/13 05:39, Cedric BAIL wrote: > > Hello, > > > > Thanks to the help of Ryuan Choi, we can announce today the release of > > a recent Webkit EFL snapshot. It is based on svn r159807. You can this > > tarball here (as it was a little bit big, I did go with xz): > > > http://download.enlightenment.org/rel/libs/webkit-efl/webkit-efl-159807.tar.xz > > . > > > > To build it, you need EFL 1.8 and libsoup 2.42 at least. Then > > something like that will do : > > mkdir build && cd build > > cmake .. -DPORT=Efl -DENABLE_WEB_AUDIO=Off -DENABLE_VIDEO=Off > > -DENABLE_VIDEO_TRACK=Off -DENABLE_ACCESSIBILITY=Off > > -DENABLE_BATTERY_STATUS=Off -DCMAKE_INSTALL_PREFIX=/usr/local > > make -j 4 > > > > Does this mean we don't support audio, video and accessibility? > > -- > Tom. > > > > -- > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics > Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Webkit EFL
On 2013-12-12 06:39, Cedric BAIL wrote: > Hello, > > Thanks to the help of Ryuan Choi, we can announce today the release of > a recent Webkit EFL snapshot. It is based on svn r159807. You can this > tarball here (as it was a little bit big, I did go with xz): > http://download.enlightenment.org/rel/libs/webkit-efl/webkit-efl-159807.tar.xz > . > > To build it, you need EFL 1.8 and libsoup 2.42 at least. Then Jenkins slave does now have libsoup 2.42 is ever build test will be done there. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Webkit EFL
On 12/12/13 05:39, Cedric BAIL wrote: > Hello, > > Thanks to the help of Ryuan Choi, we can announce today the release of > a recent Webkit EFL snapshot. It is based on svn r159807. You can this > tarball here (as it was a little bit big, I did go with xz): > http://download.enlightenment.org/rel/libs/webkit-efl/webkit-efl-159807.tar.xz > . > > To build it, you need EFL 1.8 and libsoup 2.42 at least. Then > something like that will do : > mkdir build && cd build > cmake .. -DPORT=Efl -DENABLE_WEB_AUDIO=Off -DENABLE_VIDEO=Off > -DENABLE_VIDEO_TRACK=Off -DENABLE_ACCESSIBILITY=Off > -DENABLE_BATTERY_STATUS=Off -DCMAKE_INSTALL_PREFIX=/usr/local > make -j 4 > Does this mean we don't support audio, video and accessibility? -- Tom. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Webkit EFL
Hello, Thanks to the help of Ryuan Choi, we can announce today the release of a recent Webkit EFL snapshot. It is based on svn r159807. You can this tarball here (as it was a little bit big, I did go with xz): http://download.enlightenment.org/rel/libs/webkit-efl/webkit-efl-159807.tar.xz . To build it, you need EFL 1.8 and libsoup 2.42 at least. Then something like that will do : mkdir build && cd build cmake .. -DPORT=Efl -DENABLE_WEB_AUDIO=Off -DENABLE_VIDEO=Off -DENABLE_VIDEO_TRACK=Off -DENABLE_ACCESSIBILITY=Off -DENABLE_BATTERY_STATUS=Off -DCMAKE_INSTALL_PREFIX=/usr/local make -j 4 I have tested it with elm web and it work quite well for me. I hope it will be useful for others. Just be aware that if you build it, you need around 4G of ram for the linker. This means it can only be build on 64bits system. Cross compilation is required for 32bits system. Enjoy, -- Cedric BAIL -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [webkit-efl] Deprecating WebKit EFL 1
Yop, On Thu, Nov 1, 2012 at 4:18 AM, Leandro Pereira wrote: > > On 10/31/2012 03:50 PM, Vincent Torri wrote: > > > > > http://curl.haxx.se/docs/http-cookies.html > > > > I think that if you think that libcurl has missing features, maybe you > > should ask if they exist first in the curl mailing list or its IRC > > chan. > > > > The cURL backend in WebKit is quite poor. It not only less performant > than the libsoup one, but it also lack certain things, like persistent > cookie storage support. > > The only port that uses cURL right now, if I recall correctly, is the > windows-cairo port (the official Windows port by Apple uses a > proprietary framework ported from OS X). We've used to support it as > well, but decided not to anymore due to various complications not only > with the cURL support code in WebKit, but with cURL itself, which as > powerful as it is, it's not a library that's easy to work with, > specially if you need something beyond the basics. > > Granted, since cURL itself already supports persistent cookie storage, > adding support for it in WebKit wouldn't be too difficult, I guess. I > haven't been following WebKit in a while and it might even be > implemented already. However, there are quite a lot of other things that > should be implemented that are already there in the LibSoup support > code, and they're quite tricky to be implemented with cURL. > > > I don't like to depend on GLib just for the network part as much as the > next guy, but I believe that, right now, libsoup is still our best > alternative in WebKit-EFL. Well, there is also another reason why EFL developer push for not depending on library that use GLib main loop. Integration with it is tricky, not reliable and difficult to maintain. The main reason we have it is for WebKit/EFL. If we can move away of it, the fragility and maintenance burden we have with that will be lower. That's not a move to decide quickly, but there is trade off on both side. Question is which one is the most stable and the best solution over time... I only know that our GLib integration is a pain and highly difficult to maintain in a working shape. I always recommend to move away from it... Cedric -- 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [webkit-efl] Deprecating WebKit EFL 1
On 10/31/2012 03:50 PM, Vincent Torri wrote: > > http://curl.haxx.se/docs/http-cookies.html > > I think that if you think that libcurl has missing features, maybe you > should ask if they exist first in the curl mailing list or its IRC > chan. > The cURL backend in WebKit is quite poor. It not only less performant than the libsoup one, but it also lack certain things, like persistent cookie storage support. The only port that uses cURL right now, if I recall correctly, is the windows-cairo port (the official Windows port by Apple uses a proprietary framework ported from OS X). We've used to support it as well, but decided not to anymore due to various complications not only with the cURL support code in WebKit, but with cURL itself, which as powerful as it is, it's not a library that's easy to work with, specially if you need something beyond the basics. Granted, since cURL itself already supports persistent cookie storage, adding support for it in WebKit wouldn't be too difficult, I guess. I haven't been following WebKit in a while and it might even be implemented already. However, there are quite a lot of other things that should be implemented that are already there in the LibSoup support code, and they're quite tricky to be implemented with cURL. I don't like to depend on GLib just for the network part as much as the next guy, but I believe that, right now, libsoup is still our best alternative in WebKit-EFL. Cheers, Leandro -- 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [webkit-efl] Deprecating WebKit EFL 1
On Wed, Oct 31, 2012 at 5:22 PM, ryuan Choi wrote: > 2012/11/1 Gustavo Sverzut Barbieri > >> On Wed, Oct 31, 2012 at 12:57 PM, Thiago Marcos P. Santos >> wrote: >> > On Wed, Oct 31, 2012 at 2:07 PM, Vincent Torri >> wrote: >> >> On Wed, Oct 31, 2012 at 1:03 PM, Gustavo Lima Chaves >> >> wrote: >> >>> * Cedric BAIL [2012-10-31 11:38:52 +0900]: >> >>> >> On Wed, Oct 31, 2012 at 11:23 AM, Gustavo Sverzut Barbieri >> wrote: >> > On Tue, Oct 30, 2012 at 11:53 PM, Cedric BAIL >> wrote: >> >> Hello, >> >> >> >> On Wed, Oct 31, 2012 at 1:10 AM, Christophe Dumez >> >> 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 >> >> >> > >> > Dominik has a good point about the same subject: >> > http://lists.webkit.org/pipermail/webkit-efl/2012-October/000417.html >> >> The problem is that libsoup depends on shitloads of other libraries >> just to provide HTTP. >> > >> If curl is not enough, pretty sure can turn into a task to write a >> proper implementation that fulfill WebKit needs and that is integrated >> into EFL. >> >> +1 in the viewpoint that libcurl is way to go. > But it may not be easy work. > > When we decide to use libsoup as default network backend, libcurl backend > has many missing features such as cookie,
Re: [E-devel] [webkit-efl] Deprecating WebKit EFL 1
2012/11/1 Gustavo Sverzut Barbieri > On Wed, Oct 31, 2012 at 12:57 PM, Thiago Marcos P. Santos > wrote: > > On Wed, Oct 31, 2012 at 2:07 PM, Vincent Torri > wrote: > >> On Wed, Oct 31, 2012 at 1:03 PM, Gustavo Lima Chaves > >> wrote: > >>> * Cedric BAIL [2012-10-31 11:38:52 +0900]: > >>> > On Wed, Oct 31, 2012 at 11:23 AM, Gustavo Sverzut Barbieri > wrote: > > On Tue, Oct 30, 2012 at 11:53 PM, Cedric BAIL > wrote: > >> Hello, > >> > >> On Wed, Oct 31, 2012 at 1:10 AM, Christophe Dumez > >> 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 > >> > > > > Dominik has a good point about the same subject: > > http://lists.webkit.org/pipermail/webkit-efl/2012-October/000417.html > > The problem is that libsoup depends on shitloads of other libraries > just to provide HTTP. > > If curl is not enough, pretty sure can turn into a task to write a > proper implementation that fulfill WebKit needs and that is integrated > into EFL. > > +1 in the viewpoint that libcurl is way to go. But it may not be easy work. When we decide to use libsoup as default network backend, libcurl backend has many missing features such as cookie, cache, and so on. IIRC, they are still missing features. Anyway, I will raise this item when we discuss future plan of WebKit/tizen. As for the graphics, I don't mind Ca
Re: [E-devel] [webkit-efl] Deprecating WebKit EFL 1
On Wed, Oct 31, 2012 at 12:57 PM, Thiago Marcos P. Santos wrote: > On Wed, Oct 31, 2012 at 2:07 PM, Vincent Torri > wrote: >> On Wed, Oct 31, 2012 at 1:03 PM, Gustavo Lima Chaves >> wrote: >>> * Cedric BAIL [2012-10-31 11:38:52 +0900]: >>> On Wed, Oct 31, 2012 at 11:23 AM, Gustavo Sverzut Barbieri wrote: > On Tue, Oct 30, 2012 at 11:53 PM, Cedric BAIL > wrote: >> Hello, >> >> On Wed, Oct 31, 2012 at 1:10 AM, Christophe Dumez >> 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 >> > > Dominik has a good point about the same subject: > http://lists.webkit.org/pipermail/webkit-efl/2012-October/000417.html The problem is that libsoup depends on shitloads of other libraries just to provide HTTP. If curl is not enough, pretty sure can turn into a task to write a proper implementation that fulfill WebKit needs and that is integrated into EFL. As for the graphics, I don't mind Cairo or Skia. If someone (Jorge) provides a GraphicsContext using his library would be nice as well. BR, -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- 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_oc
Re: [E-devel] [webkit-efl] Deprecating WebKit EFL 1
On Wed, Oct 31, 2012 at 2:07 PM, Vincent Torri wrote: > On Wed, Oct 31, 2012 at 1:03 PM, Gustavo Lima Chaves > wrote: >> * Cedric BAIL [2012-10-31 11:38:52 +0900]: >> >>> On Wed, Oct 31, 2012 at 11:23 AM, Gustavo Sverzut Barbieri >>> wrote: >>> > On Tue, Oct 30, 2012 at 11:53 PM, Cedric BAIL wrote: >>> >> Hello, >>> >> >>> >> On Wed, Oct 31, 2012 at 1:10 AM, Christophe Dumez >>> >> 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 > Dominik has a good point about the same subject: http://lists.webkit.org/pipermail/webkit-efl/2012-October/000417.html -- 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [webkit-efl] Deprecating WebKit EFL 1
On Wed, Oct 31, 2012 at 12:23 AM, Gustavo Sverzut Barbieri wrote: > On Tue, Oct 30, 2012 at 11:53 PM, Cedric BAIL wrote: >> Hello, >> >> On Wed, Oct 31, 2012 at 1:10 AM, Christophe Dumez >> 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? +1. Lucas De Marchi -- 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [webkit-efl] Deprecating WebKit EFL 1
On Wed, Oct 31, 2012 at 12:07 PM, Vincent Torri wrote: > On Wed, Oct 31, 2012 at 1:03 PM, Gustavo Lima Chaves > wrote: > > * Cedric BAIL [2012-10-31 11:38:52 +0900]: > > > >> On Wed, Oct 31, 2012 at 11:23 AM, Gustavo Sverzut Barbieri > >> wrote: > >> > On Tue, Oct 30, 2012 at 11:53 PM, Cedric BAIL > wrote: > >> >> Hello, > >> >> > >> >> On Wed, Oct 31, 2012 at 1:10 AM, Christophe Dumez > >> >> 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 > I cast two votes in favor of this. -- 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [webkit-efl] Deprecating WebKit EFL 1
On Wed, Oct 31, 2012 at 1:03 PM, Gustavo Lima Chaves wrote: > * Cedric BAIL [2012-10-31 11:38:52 +0900]: > >> On Wed, Oct 31, 2012 at 11:23 AM, Gustavo Sverzut Barbieri >> wrote: >> > On Tue, Oct 30, 2012 at 11:53 PM, Cedric BAIL wrote: >> >> Hello, >> >> >> >> On Wed, Oct 31, 2012 at 1:10 AM, Christophe Dumez >> >> 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [webkit-efl] Deprecating WebKit EFL 1
* Cedric BAIL [2012-10-31 11:38:52 +0900]: > On Wed, Oct 31, 2012 at 11:23 AM, Gustavo Sverzut Barbieri > wrote: > > On Tue, Oct 30, 2012 at 11:53 PM, Cedric BAIL wrote: > >> Hello, > >> > >> On Wed, Oct 31, 2012 at 1:10 AM, Christophe Dumez > >> 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. > -- > Cedric BAIL > ___ > webkit-efl mailing list > webkit-...@lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-efl -- Gustavo Lima Chaves Computer Engineer @ ProFUSION Embedded Systems -- 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [webkit-efl] Deprecating WebKit EFL 1
On Wed, Oct 31, 2012 at 12:07 PM, David Seikel wrote: > The quotations in this thread are a bit screwed. Lucas De Marchi said > the first paragraph here. I think Christophe is correctly quoted, but > that part seems to be on a different mailing list. > > On Wed, 31 Oct 2012 10:53:48 +0900 Cedric BAIL > wrote: > >> On Wed, Oct 31, 2012 at 1:10 AM, Christophe Dumez > >> >> On a side node, being a former contributor to webkit-efl, I >> >> shrugged with recent webkit revisions in which we refuse do depend >> >> and use EFL infra but we are now depending on several third-party >> >> non-released libraries. No matter what jhbuild can do for devs we >> >> should be using more of EFL, not less. >> > >> > I'm not sure what you're referring to. From what I've seen, we are >> > relying more and more on EFL, not the opposite. >> >> If that's true, that's a bad move and evolution here. But that should >> be part of another thread of discussion. > > Er, I'm confused here. Cedric thinks it's a bad move to have WedKit EFL > rely more on EFL, but ... Ah ah ah, not quite it. Exactly the opposite ! :-) -- Cedric BAIL -- 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [webkit-efl] Deprecating WebKit EFL 1
The quotations in this thread are a bit screwed. Lucas De Marchi said the first paragraph here. I think Christophe is correctly quoted, but that part seems to be on a different mailing list. On Wed, 31 Oct 2012 10:53:48 +0900 Cedric BAIL wrote: > On Wed, Oct 31, 2012 at 1:10 AM, Christophe Dumez > >> On a side node, being a former contributor to webkit-efl, I > >> shrugged with recent webkit revisions in which we refuse do depend > >> and use EFL infra but we are now depending on several third-party > >> non-released libraries. No matter what jhbuild can do for devs we > >> should be using more of EFL, not less. > > > > I'm not sure what you're referring to. From what I've seen, we are > > relying more and more on EFL, not the opposite. > > If that's true, that's a bad move and evolution here. But that should > be part of another thread of discussion. Er, I'm confused here. Cedric thinks it's a bad move to have WedKit EFL rely more on EFL, but ... > On Wed, Oct 31, 2012 at 11:23 AM, Gustavo Sverzut Barbieri > wrote: > > 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. ... then agrees WebKit EFL should use more EFL? I kinda gave up on WebKit 1 with EFL when I got a half dozen levels deep in the build dependencies my OS did not have, found GPL v3 at that level, and shuddered with horror at the thought of it contaminating everything all the way up. No idea how many more levels deep the dependencies went. My OS has everything needed to actually run WebKit as standard. How come I needed to spend all day compiling missing dependencies just to build it? Using more EFL might actually help that, by reducing the other dependencies. In the end I used uzbl, a stand alone WebKit based executable designed to be a HTML widget you feed commands to through a pipe, in the traditional "do one thing and do it well" Unix philosophy. It's not EFL, but way easier to build with, and kept any viral licenses well separated from code I want to release under BSD. I look forward to a WebKIt 2 based EFL, then I'll look at it again and see if it's still seven layers of dependency hell to build. I wonder how hard it would be to port Dillo to EFL? B-) -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [webkit-efl] Deprecating WebKit EFL 1
On Wed, Oct 31, 2012 at 11:23 AM, Gustavo Sverzut Barbieri wrote: > On Tue, Oct 30, 2012 at 11:53 PM, Cedric BAIL wrote: >> Hello, >> >> On Wed, Oct 31, 2012 at 1:10 AM, Christophe Dumez >> 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. -- Cedric BAIL -- 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [webkit-efl] Deprecating WebKit EFL 1
On Tue, Oct 30, 2012 at 11:53 PM, Cedric BAIL wrote: > Hello, > > On Wed, Oct 31, 2012 at 1:10 AM, Christophe Dumez > 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? > As a side note a fact, that I don't know more than half of the people > in this thread, means you are not really visible in EFL community. > That's bad also. We have an EFL dev day next week in Barcelona, I hope > to see and meet some of you guys there. > >>> On a side node, being a former contributor to webkit-efl, I shrugged >>> with recent webkit revisions in which we refuse do depend and use EFL >>> infra but we are now depending on several third-party non-released >>> libraries. No matter what jhbuild can do for devs we should be using >>> more of EFL, not less. >> >> I'm not sure what you're referring to. From what I've seen, we are relying >> more and more >> on EFL, not the opposite. > > If that's true, that's a bad move and evolution here. But that should > be part of another thread of discussion. > > Regards, > -- > Cedric BAIL > > -- > 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 > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [webkit-efl] Deprecating WebKit EFL 1
Hello, On Wed, Oct 31, 2012 at 1:10 AM, Christophe Dumez 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 side note a fact, that I don't know more than half of the people in this thread, means you are not really visible in EFL community. That's bad also. We have an EFL dev day next week in Barcelona, I hope to see and meet some of you guys there. >> On a side node, being a former contributor to webkit-efl, I shrugged >> with recent webkit revisions in which we refuse do depend and use EFL >> infra but we are now depending on several third-party non-released >> libraries. No matter what jhbuild can do for devs we should be using >> more of EFL, not less. > > I'm not sure what you're referring to. From what I've seen, we are relying > more and more > on EFL, not the opposite. If that's true, that's a bad move and evolution here. But that should be part of another thread of discussion. Regards, -- Cedric BAIL -- 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [webkit-efl] Deprecating WebKit EFL 1
[ CC'ing enlightenment-devel] On Tue, Oct 30, 2012 at 1:08 PM, Thiago Marcos P. Santos wrote: > Nowadays, most of the development is happening on EWK2. Maybe is time > to trace some plans and discuss about when and how to deprecate the > EWK1 API. > > Maintaining 2 APIs is like working on two different ports. You have > more bots to do gardening, more tests to run before submitting a > patch, more issues to solve, more APIs to document and write unit > tests. EFL has a small community of developers, focusing on a single > API will make us go faster and with more quality. > > > What I'm suggesting is: > > - Announce (formal announcement here and EFL-dev) that EWK1 will be > considered deprecated and thus, feature frozen, starting from > 01/jan/2013. > - Remove any EWK1 bot on 15/may/2013. > - Remove it from the trunk on 01/jun/2013. > > Cheers and please comment. 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. On a side node, being a former contributor to webkit-efl, I shrugged with recent webkit revisions in which we refuse do depend and use EFL infra but we are now depending on several third-party non-released libraries. No matter what jhbuild can do for devs we should be using more of EFL, not less. Lucas De Marchi -- 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Webkit Efl
On 12/19/2010 06:53 PM, Carsten Haitzler (The Rasterman) wrote: > On Sun, 19 Dec 2010 12:33:24 -0500 Christopher Michael > said: > >> Hi All, >> >> Was just wondering ... does the efl port of WebKit support editing yet ? >> >> Thanks, >> dh > > i don't think so :( i think that would be needed to be added. > It's my hope that it happens soon ;) I have an idea that is intriguing to me . I know webkit itself can do it dh -- "If C gives you enough rope to hang yourself, then C++ gives you enough rope to bind and gag your neighborhood, rig the sails on a small ship, and still have enough rope to hang yourself from the yardarm" - Anonymous quote from the The UNIX-HATERS Handbook -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Webkit Efl
On Sun, 19 Dec 2010 12:33:24 -0500 Christopher Michael said: > Hi All, > > Was just wondering ... does the efl port of WebKit support editing yet ? > > Thanks, > dh i don't think so :( i think that would be needed to be added. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Webkit Efl
Hi All, Was just wondering ... does the efl port of WebKit support editing yet ? Thanks, dh -- "If C gives you enough rope to hang yourself, then C++ gives you enough rope to bind and gag your neighborhood, rig the sails on a small ship, and still have enough rope to hang yourself from the yardarm" - Anonymous quote from the The UNIX-HATERS Handbook -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] WebKit/EFL 0.1 released
Hi all, I'm very proud to announce that the first WebKit/Efl release is out. Antonio has prepared a more detailed post in his blog: http://tonikitoo.blogspot.com/ I've just sent a patch to fix Eve build. As soon as it is commited you can build and run it. Eve: http://svn.enlightenment.org/svn/e/trunk/PROTO/eve WebKit/Efl: # git clone git://gitorious.org/webkit-efl/webkit-efl.git webkit # cd webkit # git checkout origin/master # git checkout -b # e.g. webkit-efl # get all dependencies installed - run |configure| to get a list of needed packages # WebKitTools/Scripts/build-webkit --efl --makeargs=<-s -jXX> # WebKitTools/Scripts/run-launcher --efl Best regards, -- André Pedralho -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
