October 2012 - webkit-efl - lists.webkit.org

Use of pimpl idiom for Ewk classes
by Dumez, Christophe 19 Oct '12

19 Oct '12

Hi, Mikhail and I are currently working on refactoring the Ewk classes to make them more C++-like, more convenience to use and less bug-prone. As part of this work, we came out with a proposal: Use pimpl idom for Ewk classes. The Ewk classes are currently defined in the private headers, with all their members public. The private headers also usually contain C-style functions to interact with the Ewk class from inside WebKit. Now, we would like to get rid of those private C functions and replace them with C++ methods in the Ewk class. The issue is that the Ewk class members are currently public meaning we can alter the members directly from outside the Ewk class implementation and bypass those class methods. At the same time, we don't want to make all the Ewk class members private and create getter / setter methods for all of them. Not only this means a lot of refactoring work and extra code, but also, this means that are public C API implementation will need to go through those getters / setters as well, instead of interacting with the class members directly. We therefore thought of using the pimpl idiom so that the class members are now stored in a POD struct in the cpp file. This effectively prevents access to them from code other than our public C API and Ewk class methods, which is what we want. The C API functions can still directly interact with the Ewk class members which is convenient. We can get rid of all C functions in the private headers and replace them with Ewk class methods. Therefore, the coding style in WK2 EFL port implementation with be more C++ oriented. I created a meta bug for this task: https://bugs.webkit.org/show_bug.cgi?id=99696 I also wrote a first patch to *show what the result looks* like for the Ewk_Download_Job class. The patch also adds convenience macros to ewk_private.h to make pimpl idiom usage simpler and less error-prone: *https://bugs.webkit.org/show_bug.cgi?id=99697* We hope you like the result as much as we do. If everyone agrees, Mikhail and I are planning to port other Ewk classes to this proposal and update the WebKit EFL coding style. Kr, -- Christophe Dumez Linux Software Engineer, PhD Intel Finland Oy - Open Source Technology Center

6 13

Re: [webkit-efl] Use of pimpl idiom for Ewk classes
by Kenneth Rohde Christiansen 18 Oct '12

18 Oct '12

Good news :-) I have hated them since the beginning, especially since it is impossible to see from the method name whether they are private or not. Kenneth On Thu, Oct 18, 2012 at 11:29 AM, Christophe Dumez <christophe.dumez(a)intel.com> wrote: > > > On Oct 18, 2012, at 12:25, Kenneth Rohde Christiansen <kenneth.christiansen(a)gmail.com> wrote: > >> Hi there, >> >> This sounds really nice :-) and is what Qt has been doing for long, so >> I am very supportive of this effort. >> >> Deos this mean that we can get rid of all of the private C methods? >> > > Yes. Please check my patch. You will see we don't need these private C functions anymore. > -- Kenneth Rohde Christiansen Senior Engineer, WebKit, Qt, EFL Phone +45 4093 0598 / E-mail kenneth at webkit.org ﹆﹆﹆

2 1

Re: [webkit-efl] webkit-efl Digest, Vol 16, Issue 16
by Krzysztof Czech 12 Oct '12

12 Oct '12

Basically neither ATK nor AT-SPI depends on each other. There is another layer between them. This layer is ATK-BRIDGE (also called atk-adaptor). It handles D-Bus communication between ATK and AT-SPI2. Generally D-Bus is also used as transport layer between AT-SPI2 and AT(screen readers etc.) ATK-BRIDGE seemed to be also standalone library that can be used in EFL environment. Regarding QT, they seem platform-neutral, maybe they do not directly use AT-SPI but there is also a layer/interface QAccessible, that handles D-Bus communication. Those three components (atk, atk-bridge, at-spi2) form one of the ways to have accessibility in Linux platform. I observed problems in EFL regarding using of ATK. Generally at the beginning we'd like to make a first step and add support for WebKit-EFL. I think porting of ATK-BRIDGE and AT-SPI2 is not mandatory on this level. Regards Krzysztof > Send webkit-efl mailing list submissions to > webkit-efl(a)lists.webkit.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.webkit.org/mailman/listinfo/webkit-efl > or, via email, send a message with subject or body 'help' to > webkit-efl-request(a)lists.webkit.org > > You can reach the person managing the list at > webkit-efl-owner(a)lists.webkit.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of webkit-efl digest..." > > > Today's Topics: > > 1. Re: Support for WAI-ARIA standard. (Raphael Kubo da Costa) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 11 Oct 2012 14:12:33 +0300 > From: Raphael Kubo da Costa <rakuco(a)webkit.org> > To: webkit-efl(a)lists.webkit.org > Subject: Re: [webkit-efl] Support for WAI-ARIA standard. > Message-ID: <87obk9nty6.fsf(a)rkubodac-x230.fi.intel.com> > Content-Type: text/plain > > Krzysztof Czech <k.czech(a)samsung.com> writes: > >> 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. > Please consider I'm a complete layman in terms of accessibility. What's > the relationship between ATK and at-spi2? Is the latter used by the > former? I remember at least Qt is using at-spi directly, so it seems to > be more platform-neutral than ATK itself. > > -- > Intel Finland Oy > Registered Address: PL 281, 00181 Helsinki > Business Identity Code: 0357606 - 4 > Domiciled in Helsinki > > > > ------------------------------ > > _______________________________________________ > webkit-efl mailing list > webkit-efl(a)lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-efl > > > End of webkit-efl Digest, Vol 16, Issue 16 > ****************************************** >

1 0

Re: [webkit-efl] Naming rules for setting APIs
by Michal G. 11 Oct '12

11 Oct '12

Hi, If I can add something to discussion, from API user perspective I prefer such naming convention ewk_settings_enable_frame_flattening_set then ewk_settings_frame_flattening_enabled_set Best regards, Michal Guzieniuk

5 7

Re: [webkit-efl] Naming rules for setting APIs
by Jinwoo Song 10 Oct '12

10 Oct '12

>> 2) for WK2 we can land patch Jinwoo's patch >> (https://bugs.webkit.org/show_bug.cgi?id=98793) I'll upload a patch for landing after minor fixes. Thanks for fast feedback and good information. :) Jinwoo ------- Original Message ------- Sender : Kenneth Rohde Christiansen<kenneth.christiansen(a)gmail.com> Date : 2012-10-10 22:05 (GMT+09:00) Title : Re: [webkit-efl] Naming rules for setting APIs For Qt it stays there because there are companies depending on QWidget's and so it will stay as a separate module in Qt5 to help the transition to the new technologies. It is not possible to add the exact same API to a QWidget based version of WebKit2, nor does it make sense to add a QWidget based version when one functional one already exists. Anyway, WebKit1 in Qt received like 0 changes in Source/WebKit beyond making sure it still builds. For EFL we don't really have plenty of different companies heavily invested in it, nor another technology requiring it, thus the change should be quite simple. So, in what cases is WebKit1 now more stable than our WebKit2 port? And can upstreaming some more patches change that? Kenneth On Wed, Oct 10, 2012 at 2:59 PM, Gyuyoung Kim wrote: >>> 1) should we change WK1 API (ewk_view.h) as it doesn't follow this rule? > > There are some talk before about maintaining WK1. Frankly, I'm not sure if > we need to maintain WK1. However, IMO, we need to take care of the WK1 until > we remove it in trunk. > At least, I think we have to keep WK1 until WK2 is stable or used for > commercial product. It looks other ports are maintaining WK1 as well. > Therefore, it would be good if you change > WK1 according to this rule, IMO. > > I hope we won't modify API after this change. Almost person don't like to > change API frequently. Any other opinion ? > > Gyuyoung. > > On Wed, Oct 10, 2012 at 9:16 PM, Grzegorz Czajkowski > wrote: >> >> Hi, >> >> IMHO Kubo's suggestion is the strongest. If we approve this convention >> what >> will happen for the current API, for both wk1 and wk2? As I result: >> 1) should we change WK1 API (ewk_view.h) as it doesn't follow this rule? >> 2) for WK2 we can land patch Jinwoo's patch >> (https://bugs.webkit.org/show_bug.cgi?id=98793) >> 3) spelling API should be adjusted - ewk_text_checker_settings.h. I will >> take of it. >> >> Regards, >> Grzegorz >> >> -----Original Message----- >> From: webkit-efl-bounces(a)lists.webkit.org >> [mailto:webkit-efl-bounces@lists.webkit.org] On Behalf Of Raphael Kubo da >> Costa >> Sent: 10 October 2012 13:43 >> To: webkit-efl(a)lists.webkit.org >> Subject: Re: [webkit-efl] Naming rules for setting APIs >> >> "Michal G." writes: >> >> > Hi, >> > >> > If I can add something to discussion, from API user perspective I >> > prefer such naming convention >> > >> > ewk_settings_enable_frame_flattening_set >> > >> > then >> > ewk_settings_frame_flattening_enabled_set >> >> It makes sense if you come from a, let's say, sane library background >> :-) >> >> For some reason, the EFL themselves use this Yoda-like convention for >> their >> calls, so we should probably follow that as well. >> >> -- >> Intel Finland Oy >> Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 >> - >> 4 Domiciled in Helsinki >> >> _______________________________________________ >> 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 > > > > > -- > Gyuyoung Kim > SW Engineer, WebKit EFL > Email : gyuyoung.kim at webkit.org > Phone : +82 10 9530 0209 > > > _______________________________________________ > webkit-efl mailing list > webkit-efl(a)lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-efl > -- Kenneth Rohde Christiansen Senior Engineer, WebKit, Qt, EFL Phone +45 4093 0598 / E-mail kenneth at webkit.org ﹆﹆﹆ _______________________________________________ webkit-efl mailing list webkit-efl(a)lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-efl

1 0

Naming rules for setting APIs
by Jinwoo Song 10 Oct '12

10 Oct '12

Hi, I'm revisiting API names and documentation of WebKit2 EFL settings. https://bugs.webkit.org/show_bug.cgi?id=98793 Currently, there is no concrete rules for API naming, so the names are inconsistent. For example: ewk_settings_enable_frame_flattening_set()/ewk_settings_enable_frame_flattening_get() vs. ewk_settings_developer_extras_enabled_set()/ewk_settings_developer_extras_enabled_get() Grzegorz suggested to use 'ewk_settings_enable_frame_flattening_set() with following rules and I also prefer this one. > 1) WK1 uses similar API, for example: ewk_view_setting_enable_frame_flattening_set > 2) Verb next to another verb (enabled_set) doesn't looks/sounds well. > 3) I'd rather prefer not using plural in API (enabled -> enable) > 4) The Spelling API bug 91854 proposes API syntax based on above suggestions (as during work on this there wasn't ewk2-settings yet). So we will have consistent API. FYI, GTK uses set_enable_frame_flattening() and Qt uses setFrameFlatteningEnabled(). So I'd like to here the opinions for the naming rule and if there is no objections for the suggested rule, I'll adjust the APIs with this one. Thanks, Jinwoo

5 6

Porting MiniBrowser to Elementary
by Dumez, Christophe 10 Oct '12

10 Oct '12

Hi, I'm writing to notify WebKit2 EFL developers that I am porting MiniBrowser to Elementary [1] and my patch is almost ready for review. MiniBrowser is an application and Elementary brings a lot of functionality (widgets, layouts, dialogs, ...) that is extremely useful to applications. The idea is to bring Elementary as an optional dependency and build MiniBrowser only if Elementary library is found. My initial patch will not add any new controls and will simply port the existing code to Elementary. This will make the code simpler though the use of layouts and an Elementary Entry widget for the URL bar. As a side effect, the URL bar will finally supports copy / paste. In the near future, Elementary will help bring more functionality such as: - Back / Refresh / Home buttons - Alert / Prompt / Confirmation windows - Tabs - ... Please tell me if you have any feedback regarding this change. [1] http://docs.enlightenment.org/auto/elementary/index.html Kr, -- Christophe Dumez Linux Software Engineer, PhD Intel Finland Oy - Open Source Technology Center

6 15

Re: [webkit-efl] Porting MiniBrowser to Elementary
by Kangil Han 10 Oct '12

10 Oct '12

Hi, I am still confused. Suppose I am a developer who is using efl-wk2 for commercializing project. Then, I find efl-wk2 shouldn't have elementary dependency because of package layer violation. However, without elementary package, I couldn't launch test program called MiniBrowser. Does this make sense? Kind regards, Kangil From: ryuan Choi [mailto:ryuan.choi@gmail.com] Sent: Wednesday, October 10, 2012 9:59 AM To: kangil.han(a)samsung.com Subject: Re: [webkit-efl] Porting MiniBrowser to Elementary His latest change just checks elementary as an optional. So, I think that webkit/efl package can avoid to include elementary package. If elementary is not available, only minibrowser will not be built. Chris, If this is acceptable for efl folks, do you have a plan to fix Eweblauncher also? Best Regards, Ryuan Choi 2012/10/10 Kangil Han <kangil.han(a)samsung.com> Hi Chris, I have a concern on below change. AFAIK, elementary, especially webview, has dependency on WebKit library. So, below change will definitely incur package cross dependency. I would prefer that you have deep discussion with EFL people on this. Kind regards, Kangil From: webkit-efl-bounces(a)lists.webkit.org [mailto:webkit-efl-bounces@lists.webkit.org] On Behalf Of Dumez, Christophe Sent: Wednesday, October 10, 2012 1:43 AM To: webkit-efl(a)lists.webkit.org Subject: Re: [webkit-efl] Porting MiniBrowser to Elementary Hi, I uploaded the patch to: https://bugs.webkit.org/show_bug.cgi?id=98748 Kr, On Tue, Oct 9, 2012 at 7:30 PM, Dumez, Christophe <christophe.dumez(a)intel.com> wrote: Hi, I'm writing to notify WebKit2 EFL developers that I am porting MiniBrowser to Elementary [1] and my patch is almost ready for review. MiniBrowser is an application and Elementary brings a lot of functionality (widgets, layouts, dialogs, ...) that is extremely useful to applications. The idea is to bring Elementary as an optional dependency and build MiniBrowser only if Elementary library is found. My initial patch will not add any new controls and will simply port the existing code to Elementary. This will make the code simpler though the use of layouts and an Elementary Entry widget for the URL bar. As a side effect, the URL bar will finally supports copy / paste. In the near future, Elementary will help bring more functionality such as: - Back / Refresh / Home buttons - Alert / Prompt / Confirmation windows - Tabs - ... Please tell me if you have any feedback regarding this change. [1] http://docs.enlightenment.org/auto/elementary/index.html Kr, -- Christophe Dumez Linux Software Engineer, PhD Intel Finland Oy - Open Source Technology Center -- Christophe Dumez Linux Software Engineer, PhD Intel Finland Oy - Open Source Technology Center _______________________________________________ webkit-efl mailing list webkit-efl(a)lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-efl

1 0

WebKit2 EFL API consistency: uri vs url
by Dumez, Christophe 08 Oct '12

08 Oct '12

Hi, Our WebKit2 EFL API is currently a bit inconsistent in its use of uri / url. Some functions use one, some use the other. The majority seems to use url though. I'm proposing that we rename uri to url in all the WebKit2 EFL APIs and documentation, for the sake of consistency. if you disagree with this change, speak now or forever hold your peace :) Kr, -- Christophe Dumez Linux Software Engineer, PhD Intel Finland Oy - Open Source Technology Center

4 6

How about switching backing store of DRT to single?
by ryuan Choi 08 Oct '12

08 Oct '12

Dear webkit-efl developers, I want your opinion about switching default backing store of DRT(DumpRenderTree/Efl) to `single` instead of `tiled`. Now, default is `tiled` and DRT_USE_SINGLE_BACKING_STORE environment is used to switch. As you may know, DRT/Efl can not pass some pixel tests. Although it is because of many bugs, I think that one of major reason is that DRT/Efl calls paint() directly instead of capturing. So I created https://bugs.webkit.org/show_bug.cgi?id=79853 but it was reverted because of many regressions. In my poor analyze, webkit/efl can not capture the webivew now because webkit/efl does not draw mockScrollbar as calling paintContents() instead of paint() One simple solution is adding logic to paint scrollbar in _ewk_view_tiled_render_cb (ewk_view_tiled.cpp) But, I am not sure that painting scrollbar for DRT in tile is reasonable. When we designed tiled backingstore, we focused performance and I think that painting scrollbar is not a role of tile. Instead, I suggest using ewk_view_single for DRT. ewk_view_single is simple and similar with other ports. I think that ewk_view_single is more suitable for layout test. Could you let me know your opinion? Regards, Ryuan Choi

3 3