- webkit-efl - lists.webkit.org

Re: [webkit-efl] Turning on AC in webkit-efl
by Ryuan Choi 08 Nov '12

08 Nov '12

Hi, yael. I hope that we can enable this. But I want to check whether applications work well when elm_engine is not one of opengl backends. Now, MiniBrowser set preferred_engine to opengl_x11, but almost EFL applications might not specify backends and default engine might be software_x11. I want to know whether we have fallback mechanism for them. Best Regards, Ryuan Choi ------- Original Message ------- Sender : yael aharon<yael.aharon.m(a)gmail.com> Date : 2012-11-08 11:03 (GMT+09:00) Title : [webkit-efl] Turning on AC in webkit-efl Hello, I'd like to turn on ACCELERATED_COMPOSITING by default for webkit-efl. This is tracked in https://bugs.webkit.org/show_bug.cgi?id=101526. thanks, Yael +------------------------------------------------------------------------ Listen and listen and listen -----------------------+

3 2

Garden-o-Matic online
by Thiago Marcos P. Santos 08 Nov '12

08 Nov '12

We now have a Garden-o-Matic page for EFL. http://build.webkit.org/TestFailures/garden-o-matic.html?platform=efl This tool should be a replacement for http://build.webkit.org/TestFailures/ and rebaseline server in the future. (if the page doesn't work for you, try force reload because the old version might be in the cache) Cheers,

3 2

Turning on AC in webkit-efl
by yael aharon 08 Nov '12

08 Nov '12

Hello, I'd like to turn on ACCELERATED_COMPOSITING by default for webkit-efl. This is tracked in https://bugs.webkit.org/show_bug.cgi?id=101526. thanks, Yael

1 0

Switching Intel's Wk1 Debug bot to Wk2 Release
by Dominik Röttsches 07 Nov '12

07 Nov '12

Hi all, we're switching Intel's Wk1 Debug Bot to a Wk2 Release configuration. Tracked in: https://bugs.webkit.org/show_bug.cgi?id=101345 Regards, Dominik -- Dominik Röttsches <dominik.rottsches(a)intel.com>

2 1

Support for WAI-ARIA standard.
by Krzysztof Czech 02 Nov '12

02 Nov '12

Dear EFL folks, We are planning to add support for WAI-ARIA standard in WebKit EFL port. At the beginning we'd like to have all layout tests related to WAI-ARIA to be passed. We consider usage of Accessible Toolkit (ATK) library. ATK describes sets of independent interfaces that can be adopted by application's widgets to be accessible. What are pros and cons of such a solution. Pros: - ATK is a toolkit independent API. Cons: - ATK is implemented using the Glib GType and Glib interface system which further means it heavily relies on it. - EFL doesn't support ATK (but it's not required by WAI-ARIA) Here is a link to the master bug related to this topic: https://bugs.webkit.org/show_bug.cgi?id=98895 I'm looking forward of hearing opinions about this idea. Regards Krzysztof Czech

5 7

Fwd: [webkit-dev] Slide deck: How WebKit Works
by Thiago Marcos P. Santos 02 Nov '12

02 Nov '12

In case someone missed this one... Excellent reading. ---------- Forwarded message ---------- From: Adam Barth <abarth(a)webkit.org> Date: Wed, Oct 31, 2012 at 8:30 PM Subject: [webkit-dev] Slide deck: How WebKit Works To: webkit-dev(a)lists.webkit.org Below are some slides I presented yesterday that give a high-level overview of how WebKit works: https://docs.google.com/presentation/pub?id=1ZRIQbUKw9Tf077odCh66OrrwRIVNLv… Unfortunately, the talk was not recorded, but I wanted to share the slide deck in case they're useful to you. I've also added the link to <http://www.webkit.org/coding/technical-articles.html>. Thanks! Adam _______________________________________________ webkit-dev mailing list webkit-dev(a)lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev

1 0

Re: [webkit-efl] [E-devel] Deprecating WebKit EFL 1
by Cedric BAIL 31 Oct '12

31 Oct '12

On Wed, Oct 31, 2012 at 11:23 AM, Gustavo Sverzut Barbieri <barbieri(a)profusion.mobi> wrote: > On Tue, Oct 30, 2012 at 11:53 PM, Cedric BAIL <cedric.bail(a)free.fr> wrote: >> Hello, >> >> On Wed, Oct 31, 2012 at 1:10 AM, Christophe Dumez >> <christophe.dumez(a)intel.com> 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

4 3

Re: [webkit-efl] [E-devel] Deprecating WebKit EFL 1
by Lucas De Marchi 31 Oct '12

31 Oct '12

On Wed, Oct 31, 2012 at 12:23 AM, Gustavo Sverzut Barbieri <barbieri(a)profusion.mobi> wrote: > On Tue, Oct 30, 2012 at 11:53 PM, Cedric BAIL <cedric.bail(a)free.fr> wrote: >> Hello, >> >> On Wed, Oct 31, 2012 at 1:10 AM, Christophe Dumez >> <christophe.dumez(a)intel.com> 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

1 0

Common ref and unref functions for EFL WK2 objects
by Pozdnyakov, Mikhail 31 Oct '12

31 Oct '12

Hi, I've already mentioned the proposal at http://lists.webkit.org/pipermail/webkit-efl/2012-October/000393.html but think (and since nobody replied so far) it deserves new topic and new thread, so duplicating proposal again here. As all the ref-counting EWK classes are inherited from WTF::RefCounted it is possible now to have generic REF/UNREF functions in the public API instead of having separate pair of such functions for every object. To say in more details we could introduce struct Ewk_Ref_Counted Ewk_Ref_Counted; and following generic functions: EAPI Ewk_Ref_Counted* ewk_ref(Ewk_Ref_Counted*); EAPI ewk_unref(Ewk_Ref_Counted*); then Ewk_Back_Forward_List_Item might be declared for instance as typedef Ewk_Ref_Counted Ewk_Back_Forward_List_Item; so that it's clear that Ewk_Back_Forward_List_Item is ref-countable (or we could just mention in docs that given object is ref counted). Would like to hear your opinion about this proposal. BTW, WK2 C API has geneiric ref/unfer functions and GTK also does. BR, Mikhail --------------------------------------------------------------------- Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

6 8

Re: [webkit-efl] Project goals - was Fwd: Re: Re: [E-devel] Deprecating WebKit EFL 1
by Laszlo Gombos 31 Oct '12

31 Oct '12

Hi, I think it is important for the project to have a sense of common goals and directions. Clearly there is some discussion on the future of Webkit1. I think it would be beneficial to agree first on the primary goal of the project - which I think is to aid developing a browser application and for the browser use-case the project recommends (not necessary mandates) WebKit2 (and not WebKit1). It is important to acknowledge that the Webkit1 part of the project might serve other different use-cases in addition to browser development especially for limited SW and HW environments. The scope of how much of these other use-cases are served by the project should be discussed together with the WebKit1 discussion. It might be too obvious for most of you by now that the primary goal of the project is to aid browser development and that for browser development the project recommends WebKit2, but I still think it is good to get a confirmation on the list that this is the case - and perhaps document this decision in the wiki. I think getting an agreement on this part would further help us with the WebKit1 discussion. Thoughts ? Any disagreement on this ? Are there more primary goals ? Thanks, Laszlo Ps.: The current goal that I found in our wiki states the following - "WebKit/EFL is a project aiming at porting WebKit to the Enlightenment Foundation Libraries.". I find this too broad to serve this discussion. On Wed, Oct 31, 2012 at 1:56 PM, Gyuyoung Kim <gyuyoung.kim(a)samsung.com>wrote: > Hi, > > I think this talk is too faster. There is no any Tizen product based on > WK2 EFL yet. Beside some of other Samsung projects start | consider to use > WK1 EFL internally as well as latest elementary library is still using WK1 > as Cedric said. I would suggest to talk this issue after both stable WK2 > EFL is released as commercial product and elementary uses WK2 EFL instead > of WK1 without any problems. In addition, I don't think there was big > effort to maintain WK1 port. They were just bug fixings or adjust WK2 > features into WK1 so far. > > BTW, as Cedric said, WebKit EFL contributors haven't been collaborated > with EFL dev well. Although EFL contributors've been tried to use EFL > libraries as much as possible, there might be some missing EFL usage even > though they could use. I think we need to try to collaborate with EFL > developers further and further. > > Gyuyoung. > > ------- Original Message ------- > Sender : Cedric BAIL > Date : 2012-10-31 11:38 (GMT+09:00) > Title : Re: [webkit-efl] [E-devel] 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 > _______________________________________________ > webkit-efl mailing list > webkit-efl(a)lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-efl > _______________________________________________ > webkit-efl mailing list > webkit-efl(a)lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-efl >

3 2