February 2013 - webkit-efl - lists.webkit.org

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