January 2013 - webkit-efl - lists.webkit.org

how to develop a plugin in efl-webkit
by Nash Steve 01 Feb '13

01 Feb '13

I have develop a webapp in efl-webkit, and now i want to find a method to replace the node-js; and i find that tizen-device api may be possible, but i can not find any artice introduce how to develop a plugin in efl-webkit; Anyone can you tell me how to do that ? Thanks!

2 1

How to see the debug border and repaint count for Accelerated Compositing.
by Dongsung Huang 30 Jan '13

30 Jan '13

Hi folks! Before yesterday, only Coordinated Graphics System showed the debug border and repaint count for a tiled layer. Now both Coordinated Graphics System and Texture Mapper can show the debug border and repaint count. If you run Qt WK1, WK2, EFL WK2, GTK WK1 and WK2, you can see the debug visuals when setting WEBKIT_SHOW_COMPOSITING_DEBUG_VISUALS environment value to 1. like > WEBKIT_SHOW_COMPOSITING_DEBUG_VISUALS=1 ./MiniBrowser I hope it helps your debugging :) https://bugs.webkit.org/show_bug.cgi?id=105787 is the related bug. In addition, if you set setShowDebugBorders() and setShowRepaintCounter() in Settings, you can see the debug visuals also, without the strange environment setting. Cheers! Dongsung Huang p.s. I tried to amend https://trac.webkit.org/wiki/CoordinatedGraphicsSystem, but it seems like I don't have authority. Could anyone help me?

1 0

Moving the EFL WebKit2 public APIs to outside WebKit2 directory
by Thiago Marcos P. Santos 23 Jan '13

23 Jan '13

Hi Ewkitters, The recent changes on the reviewing policy for the code located inside Source/WebKit2 directory has been affecting the speed of how the EFL port moves forward. The additional burden for the WebKit2 Owners to review code from all the the ports has obviously its implications. We have red bots for days because of pending patches. We can minimize this overhead and let the WebKit2 Owners focus on reviewing the core components by moving the EFL WK2 public API and unit tests to outside the Source/WebKit2 directory. The best place I see would be Source/Platform/efl, which will be consistent with how the Chromium API files are placed inside the WebKit tree. This is the directory structure I'm proposing (using Chromium as role model): Source/WebKit2/UIProcess/API/efl/ (public headers) -> Source/Platform/efl/public Source/WebKit2/UIProcess/API/efl/ (the rest) -> Source/Platform/efl/src Note that we are initially moving _only_ the API and utests. Other things, which are probably 5% of what is left of EFL code, can be moved later if needed. Comments anyone? I'm volunteering myself for the task. Cheers,

15 29

Re: [webkit-efl] Moving the EFL WebKit2 public APIs to outside WebKit2 directory
by Gyuyoung Kim 22 Jan '13

22 Jan '13

I agree with this change. However, I'm concering how to go out of WebKit2 directory. I think it is not meaaningful work that API is only moved to out of WebKit2. On the other hands, how to follow WebKit2 change up if we move all stuff to out of WebKit2. I think QT, GTK and EFL need to collaborate on this change. How about adding this thread to webkit-gtk, qt mailing list ? Cheers, Gyuyoung. On Jan 22, 2013 9:56 AM, "yael aharon" <yael.aharon.m(a)gmail.com> wrote: I agree with Slava that if we go ahead and move the code, it should be everything, not just the API. Yael On Mon, Jan 21, 2013 at 12:52 PM, Vyacheslav Ostapenko <ostap73(a)gmail.com>wrote: > Hi All, > > Why only API part? I think everything that is not used by apple should > go outside of Source/WebKit2. > We should create something like Source/WebKit2Ports, shadow the > structure of WebKit2 there and move all the code that is not compiled by > Apple, like APIs, CoordinatedGraphics, shared memory and process mangement > and etc. > Of course it will not solve the problem of Apple breaking Qt, EFL and > GTK ports, but at least it will allow easier fixes of port specific issues. > > Slava > > On Mon, Jan 21, 2013 at 11:48 AM, Thiago Marcos P. Santos < > tmpsantos(a)gmail.com> wrote: > >> Hi Ewkitters, >> >> The recent changes on the reviewing policy for the code located inside >> Source/WebKit2 directory has been affecting the speed of how the EFL >> port moves forward. The additional burden for the WebKit2 Owners to >> review code from all the the ports has obviously its implications. We >> have red bots for days because of pending patches. >> >> We can minimize this overhead and let the WebKit2 Owners focus on >> reviewing the core components by moving the EFL WK2 public API and >> unit tests to outside the Source/WebKit2 directory. The best place I >> see would be Source/Platform/efl, which will be consistent with how >> the Chromium API files are placed inside the WebKit tree. >> >> This is the directory structure I'm proposing (using Chromium as role >> model): >> >> Source/WebKit2/UIProcess/API/efl/ (public headers) -> >> Source/Platform/efl/public >> Source/WebKit2/UIProcess/API/efl/ (the rest) -> Source/Platform/efl/src >> >> Note that we are initially moving _only_ the API and utests. Other >> things, which are probably 5% of what is left of EFL code, can be >> moved later if needed. >> >> Comments anyone? I'm volunteering myself for the task. >> >> Cheers, >> _______________________________________________ >> 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 > > _______________________________________________ webkit-efl mailing list webkit-efl(a)lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-efl

1 0

Announce: Rebaseline for enabling subpixel layout
by Dominik Röttsches 15 Jan '13

15 Jan '13

Hi all, just as a heads up - assuming that we get the large number new baselines ready, we're planning to land this patch for enabling subpixel layout and updating freetype to 2.4.11 tomorrow (EEST) https://bugs.webkit.org/show_bug.cgi?id=106774 Since we will upload the new baselines in chunks, probably at the end of the (European) day tomorrow (16.1.), there might be a period where the bots will become pretty red. I'll post when we're done so that you can all download the new LayoutTest expectations. Regards, Dominik -- Dominik Röttsches <dominik.rottsches(a)intel.com>

1 0

FW: window.showModalDialog()
by Sun, Xun 07 Jan '13

07 Jan '13

Hi folks, I posted this query on the product-dev(a)lists.tizen.org list but got no comments so far. Could someone please comment if window.showModalDialog() would be a welcomed feature for Webkit-efl? (Webkit2 of course) And what would it take? It looks like something needs to be done in the UIClientEfl, but I failed to find the place for real implementation. Thanks & Regards Xun Sun -----Original Message----- From: Sun, Xun Sent: Tuesday, December 25, 2012 9:19 AM To: product-dev(a)lists.tizen.org Subject: window.showModalDialog() Hi, In the small application we are developing, we want to show a modal dialog to the user and get response back for processing. It turns out window.showModalDialog() is not working - no dialog is popped up. Googling around I found this bug that might be related - https://bugs.webkit.org/show_bug.cgi?id=84589 So what would it take to implement this function into webkit-efl? Is this planed? Thanks & Regards Xun Sun

3 4