- webkit-efl - lists.webkit.org

Changing the test expectations lookup sequence
by Thiago Marcos P. Santos 07 Mar '13

07 Mar '13

Hi EWebkitters, Currently on the EFL WK2 port, the lookup sequence for test expectations is "efl-wk2 -> wk2 -> efl -> generic". The "efl" part of this sequence is shared between EFL WebKit1 and EFL WebKit2. I'm currently facing some challenges when gardening because of: 1. Currently we have some tests skipped (~90) on the "wk2" expectations that have different expectations on "efl". It gives you the impression that the test is running (because is marked as [ Failure ] when in fact is being skipped because "wk2" has precedence. The flakiness dashboard also gets confused about it and gives a false positive. 2. Removing or adding a file to the shared expectation requires testing on both ports, which IMO is a heavy burden. 3. I'm trying to remove from the flaky list some tests that are now considered stable (no failures on the past 100 runs). Because of the shared expectations, I will have to analyse the results of one extra bot, even though I have no intentions of doing gardening for WebKit1. I would like to suggest changing the lookup sequence to "efl-wk2 -> wk2 -> generic", so we can make EFL WK2 port completely independent. Cheers,

6 5

Render issue
by Daniel Robinson 04 Mar '13

04 Mar '13

I'm running WebKit EFL on a CentOS 6.3 machine. When I run the MiniBrowser, I get an all white page. I'm running on a virtual machine and using Xvfb. I am trying to load a well known site, google.com. When I do this with Firefox, I can use xwd to grab the root plane of the display and Firefox is rendering the Google page. When I run the MiniBrowser, I know that it is accessing www.google.com because I see the network traffic with tshark. I can paint an arbitrary box in the display with Xlib calls. Using xwd, I can retrieve that. Two thoughts: 1) Webkit is waiting for input of some kind. Perhaps, but when I set the DISPLAY variable to "localhost:14.0" or whatever, I see the window on my workstation and by trying a number of things happen. If I press the mouse button at various points in the window, the URL in the URL window changes to reflect new pages being loaded. 2) Some permission requirement is not being met. I have built the MiniBrowser in debug mode and when it quits, it lists the objects it has rendered. Any help would be appreciated. --dan robinson -- ----------------------- daniel g. robinson www.bornlivelovedie.com bornlivelovedie.tumblr.com @daguro

1 0

Removal of non coordinated graphics code path from WK2 EFL
by Pozdnyakov, Mikhail 15 Feb '13

15 Feb '13

Hi folks! I would like to know your opinion about removal of non coordinated graphics code path from WK2 EFL as it seems nobody is using it and keeping eye on it. This removal would make our code look much better without unused code branches and ugly #if USE(ACCELERATED_COMPOSITING) , #if USE(TILED_BACKING_STORE), #if USE(COORDINATED_GRAPHICS) 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.

9 10

Building on CentOS 6.3?
by Daniel Robinson 08 Feb '13

08 Feb '13

Are there any list members building WebKit/EFL on CentOS 6.3 (x86_64)? I have run into problems with cmake and pkg-config. I have built WebKit/EFL successfully on Ubuntu 12.04 (32 bit) with no issues. For reasons that I don't understand, libsoup and other components (glibc, etc) are not found in the WebKitBuild/Dependencies directory. Thanks, Dan -- ----------------------- daniel g. robinson www.bornlivelovedie.com bornlivelovedie.tumblr.com @daguro

5 9

Fwd: [webkit-qt] APIs going forward
by Kenneth Rohde Christiansen 04 Feb '13

04 Feb '13

FYI, ---------- Forwarded message ---------- From: Simon Hausmann <simon.hausmann(a)digia.com> Date: Mon, Feb 4, 2013 at 11:13 AM Subject: [webkit-qt] APIs going forward To: webkit-qt(a)lists.webkit.org Hi, I see an increasing demand in exposing features in the QML API. Some of those features don't really fit naturally in it but are necessary to accomplish what seem like basic tasks. Consequently we're facing a difficult time between finding an intuitive QML API, keeping things slim and maintainable but still making it possible to do certain things. At the same time on the implementation side we're seeing the need to improve our layering and encapsulation. It is our intention to separate the QML specific bits in WebKit2 from the non-QML specific bits and use a similar layering as the other ports between then, i.e. 90% of the functionality is covered by the C API and the remaining 10% are covered by a (Qt) port specific view class. So how are the two related, demand of richer API and "implementation details" of the QML webview? Well, if we do this right then the QML2 webview would be implemented on top of a semi-stable 90% C based API that is shared between all ports of WebKit2. That changes how we can perceive WebKit as a library in the system: (1) It looks like a "third-party" library that uses Qt, provides a mostly C based low-level API that provides strictly speaking no stability guarantees but gives full access to WebKit. Think of it as a library like libpng or libicu, it just happens to use Qt under the bonnet. (2) A separate QML2 integration is based on the same API and connects WebKit with QML. It comes with the full Qt API promise of stability and compatibility. The separation allows us to keep the QML API minimal and simple, following one of the Qt principles that the common things should be easy to do. If you need more then you'll have to fall back to the underlying library that provides a lower level API. If done right it would be possible to combine the two, i.e. if you'd like to use the QML webview in your application but need to fine-tune one aspect really specific to your use-case (say the cookie storage location or making sure that you have a dedicated web process), then you would be able to connect the QML webview with the underlying WebKit2 C API that. How does that sound? If you're interested in helping us take this direction, feel free to join the hackery and use the master bug at https://bugs.webkit.org/showdependencytree.cgi?id=108471&hide_resolved=1 for tracking and coordination (as well as IRC naturally). Simon _______________________________________________ webkit-qt mailing list webkit-qt(a)lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-qt -- Kenneth Rohde Christiansen Senior Engineer, WebKit, Qt, EFL Phone +45 4294 9458 / E-mail kenneth at webkit.org ﹆﹆﹆

1 0

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