- webkit-efl - lists.webkit.org

Drawing the Cairo Surface
by Sanjeev BA 03 Sep '12

03 Sep '12

Dear EFL Webkit members, I read from the efl webkit porting page that the port uses cairo for rendering. Can someone explain to me how this is done or which source files to look at regarding the implementation? Regards, Sanjeev

2 1

Good manners are important even among close friends
by Kangil Han 24 Aug '12

24 Aug '12

Dear webkit-efl developers, First of all, I regret that I am writing about *manners* to webkit-efl community. I strongly believe we should encourage developers to make efl port better day by day. To do this, we should praise developer's idea on the bug if it is good otherwise guide them to the right place by proper review. This morning I feel frustrated when I wanted to continue my investigation on the bug because it already was finished. This makes me feel wasting my time on that bug and even being stolen my idea by someone. I hope no one would do this again from now on and port reviewers would care about this. Thanks, Kangil Han

1 0

API Unit Tests
by Thiago Marcos P. Santos 20 Aug '12

20 Aug '12

Hi WebKit EFL, Thanks to the great work done by Krzysztof at the bug 68509, we have now an API Unit Test Framework for EWK. You can run the tests individually or all tests at once by calling the runner script: $ ./Tools/Scripts/run-efl-tests [--debug|--release] The runner was integrated as a step of the build bots running tests. The only thing missing now is test coverage, and I hope the EFL community can work together at the meta bug tracking the missing tests [1]. I strongly recommend if you are working on a test, to add as dependency to this bug to give visibility to all the developers involved on the task. Another suggestion would be that we do not accept any addition/modification to the APIs if there is no test backing the change. IMO this is aligned to the WebKit best practices and can only bring benefits to the port. [1] https://bugs.webkit.org/show_bug.cgi?id=90451 Cheers!

3 5

HEADS-UP: Change to the default behavior of build-webkit and jhbuild
by Raphael Kubo da Costa 17 Aug '12

17 Aug '12

Hi everyone, Some of you may have noticed that after bug 93208 landed, the jhbuild dependencies would always be updated regardless of any configuration change, which was quite annoying. Since r125862, we behave more similarly to the WebKitGTK+ port in two ways: first, build-webkit will update the jhbuild modules *only* if --update-efl is passed as an argument; secondly, jhbuild itself will only be used if $WEBKITOUTPUTDIR/Dependencies exists. Important corollaries: - If you check out a clean tree and run build-webkit, jhbuild will *not* be used by default and the system libraries will be used until build-webkit --update-efl is used and $WEBKITOUTPUTDIR/Dependencies starts existing. - Even if you have already bootstrapped jhbuild, you need to periodically (or always) pass --update-efl to build-webkit for it to check if any of its modules need to be updated. So if we bump some dependency version in, say, OptionsEfl.cmake, you may experience some CMake failure if you don't update your jhbuild modules. The bots shouldn't experience any change, by the way, since --update-efl is now run by default by them.

4 5

Dropping support for the pango network backend.
by ryuan Choi 17 Aug '12

17 Aug '12

Hello, Efl folks. We've supported freetype and pango backend as font backend of webkit-efl. However, pango backend can not render well because of missing features and webkit-efl builds with freetype by default. Does anyone need pango backend? If possible, I will remove font backend selection checks and just use freetype backend with FontPango.cpp for the complex font. Related bug is https://bugs.webkit.org/show_bug.cgi?id=86369 Best Regards, Ryuan Choi

4 8

Remove an item in EFL coding style document
by Gyuyoung Kim 16 Aug '12

16 Aug '12

Hello EFL folks, I would like to remove below coding style from EFL port coding style document. Because, this is not EFL port specific coding style. In my opinion, EFL port needs to follow WebKit coding style for constant variable. == Use const keyword instead of #define when you define constant variable == Right const int defaultTileWidth = 256; const int defaultTileHeigth = 256; Wrong #define DEFAULT_TILE_W (256) #define DEFAULT_TILE_H (256) If there are any objections or feedback, please let me know. :-) Cheers, Gyuyoung

2 1

Support --pixel-test on layout test
by Gyuyoung Kim 16 Aug '12

16 Aug '12

Hello EFL folks, As you know, EFL port doesn't support -pixel-test feature so far correctly. In my opinion, it looks now is time to start to support -pixel-test. However, unfortunately, EFL build bots don't support -pixel-test. We need to verify this on local environment first. If you have good solution, please let us know. It looks Ubuntu 12.04 64-bit platform is proper target device for now. I file a meta bug for this. [Meta][EFL] Support -pixel-test for layout test. https://bugs.webkit.org/show_bug.cgi?id=94188 Cheers, Gyuyoung.

1 0

WKEinaSharedString
by Pozdnyakov, Mikhail 14 Aug '12

14 Aug '12

Hi, New WKEinaSharedString class was added at r125035. It is basically a smart pointer for Eina_Stringshare . You may use it to save some lines of code and be safe about invoking eina_stringshare_del in time. Example of using WKEinaSharedString can be found at Source/WebKit2/UIProcess/API/efl/ewk_back_forward_list_item.cpp. 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.

3 2

Re: [webkit-efl] Call stack of webkit-efl using cairo api
by satya appidi 13 Aug '12

13 Aug '12

Hi Raphael, I am debugging , webkit-efl debug build . i am running the EWebLauncher, Minibrowser app. i wanna find the call statck ( webkit -> EFL -> CAIRO ). Since the source code of EFL and cairo was not part of WEbkit souce code, i am not able to step into EFL Api's . Plz help, what else i need to do. *or * How link the separate debug build of EFL and CAIRO libraries with WEBKIT-EFL debug build Br, satya... On Wed, Aug 8, 2012 at 1:01 PM, Raphael Kubo da Costa <rakuco(a)webkit.org>wrote: > Dominik Röttsches <dominik.rottsches(a)intel.com> writes: > > > Hi Ryuan, > > > > On 05/15/2012 10:22 AM, ryuan Choi wrote: > >> We've supported freetype and pango backend as font backend of > webkit-efl. > >> > >> However, pango backend can not render well because of missing > >> features and webkit-efl builds with freetype by default. > >> Does anyone need pango ? > >> If possible, I will remove font backend selection checks and just > >> use freetype backend with FontPango.cpp for the complex font. > >> > >> Related bug is https://bugs.webkit.org/show_bug.cgi?id=86369 > > > > I remember Martin Robinson prefers to not mix those backends and wait > > for his HarfBuzz support to be merged. I asked him on IRC and he has a > > preliminary patch that he's planning to upstream soon. See also > > https://bugs.webkit.org/show_bug.cgi?id=83275 > > For posterity and also for people not watching Bugzilla: harfbuzz > support has been added by Dominik, and using the freetype backend now > requires HarfBuzz >= 0.9.0. > > The Pango backend has not been dropped yet, but using it does not seem > to bring any benefits over harfbuzz these days. > > _______________________________________________ > webkit-efl mailing list > webkit-efl(a)lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-efl >

2 1

RFC: Bumping the minimum CMake version to 2.8.3
by Raphael Kubo da Costa 10 Aug '12

10 Aug '12

Hi everyone, My work on [1] has brought up a proposal to bump the minimum CMake version required to build any of the CMake-based ports to 2.8.3. [1] https://bugs.webkit.org/show_bug.cgi?id=93189 The immediate benefits of this would be the possibility to use FIND_PACKAGE_HANDLE_STANDARD_ARG()'s extended syntax and some other syntatic sugars which would eliminate some FIXMEs from the files in Source/cmake. This would also make my patch [2] to rewrite FindLibSoup2.cmake a bit smaller, and help pave the way for the rewrite of FindEFL.cmake I have in mind (along with my "why relying solely on PKG_CHECK_MODULES() is a bad thing" FAQ :-) CMake 2.8.3 was tagged in early November, 2010, and is part of Ubuntu 11.04, so anyone still on 10.10 would need to upgrade. Thoughts?

2 6