- webkit-efl - lists.webkit.org

Fwd: Re: Re: [E-devel] Deprecating WebKit EFL 1
by Gyuyoung Kim 31 Oct '12

31 Oct '12

Hi, I think this talk is too faster. There is no any Tizen product based on WK2 EFL yet. Beside some of other Samsung projects start | consider to use WK1 EFL internally as well as latest elementary library is still using WK1 as Cedric said. I would suggest to talk this issue after both stable WK2 EFL is released as commercial product and elementary uses WK2 EFL instead of WK1 without any problems. In addition, I don't think there was big effort to maintain WK1 port. They were just bug fixings or adjust WK2 features into WK1 so far. BTW, as Cedric said, WebKit EFL contributors haven't been collaborated with EFL dev well. Although EFL contributors've been tried to use EFL libraries as much as possible, there might be some missing EFL usage even though they could use. I think we need to try to collaborate with EFL developers further and further. Gyuyoung. ------- Original Message ------- Sender : Cedric BAIL Date : 2012-10-31 11:38 (GMT+09:00) Title : Re: [webkit-efl] [E-devel] Deprecating WebKit EFL 1 On Wed, Oct 31, 2012 at 11:23 AM, Gustavo Sverzut Barbieri wrote: > On Tue, Oct 30, 2012 at 11:53 PM, Cedric BAIL wrote: >> Hello, >> >> On Wed, Oct 31, 2012 at 1:10 AM, Christophe Dumez >> wrote: >>>> There are lots of concerns from EFL developers (me included) on how >>>> the development of WebKit-EFL is being done. The API of webkit2 even >>>> not being fully supported by EFL, as contrary to webkit1. There's only >>>> 1 developer that seemed to care and started to send patches to >>>> elm-web, so webkit2 can be fully supported. >>>> >>>> No surprise there was feedback asking for clarifications and why a >>>> simpler api couldn't be used. Now you come and say WebKit1 is being >>>> deprecated. -1000 here, until the day webkit2 gets fully supported in >>>> EFL and you start to interact more with EFL devs. >>> >>> The proposed date for dropping WK1 EFL from upstream is 8 month away. I think this >>> gives a reasonable amount of time for people currently relying on WK1 EFL to port their code to WK2 EFL. >>> If anything, this should motivate people to make sure all the components work with WK2 EFL. >> >> 8 months is clearly to short from now is clearly to short. 8 months >> after WK2 EFL API is stabilized and "released" (I mean by that, that >> any API/ABI break of it will be forbidden). Then you can consider >> dropping WK1 EFL. Announcing that you will drop WK1 EFL when WK2 EFL >> is not even stable, is not a proper move in my opinion. >> >> Upstream EFL does use WK1 EFL in the 1.7.x branch, that will be used >> by E17 release later this year. This means that all distribution that >> do want to package EFL with a stable release for E17 will be depending >> on WK1 EFL. You can stop development, only do bugfixes, but removing >> it is clearly not a smart move here. >> >>> About interaction with EFL developers, I don't think we have any problem answering questions related >>> to WebKit EFL (via this mailing list or the IRC channel) or fix bugs filed upstream against WebKit EFL. >> >> Yes, you have. I am aware of the move to WK2 EFL since less than 3 >> weeks. If some nice Samsung guy didn't try to help EFL upstream to >> move away of WK1 EFL we wouldn't be even have any proper information >> and code here. At this point, the WebKit EFL people need to get more >> involved with EFL. It's not a matter of answering question, it's about >> using the same tool and do that efficiently ! If we don't share >> infromation more effectively, this kind of thread is going to repeat. >> I strongly encourage every developer of WK EFL to join e-devel mailing >> list and ping people there when there is important subject to bring in >> (like new dependencies, feature request, ...). I am now subscribed to >> this mailing list and will try to keep reading it, but that's not >> enough. WK EFL team should get more engadged with EFL developer in >> general. > > As a related note: although Ecore provides curl/http, WebKit still > uses the crap alien that is libsoup. Why not start the Webkit + EFL > adding the missing bits to Ecore_Con and then using it natively in > WebKit, instead of forcing glib-mainloop integration for nothing? I can't but only agree and wish for that to happen soon. -- Cedric BAIL _______________________________________________ webkit-efl mailing list webkit-efl(a)lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-efl

1 0

Deprecating WebKit EFL 1
by Thiago Marcos P. Santos 31 Oct '12

31 Oct '12

Nowadays, most of the development is happening on EWK2. Maybe is time to trace some plans and discuss about when and how to deprecate the EWK1 API. Maintaining 2 APIs is like working on two different ports. You have more bots to do gardening, more tests to run before submitting a patch, more issues to solve, more APIs to document and write unit tests. EFL has a small community of developers, focusing on a single API will make us go faster and with more quality. What I'm suggesting is: - Announce (formal announcement here and EFL-dev) that EWK1 will be considered deprecated and thus, feature frozen, starting from 01/jan/2013. - Remove any EWK1 bot on 15/may/2013. - Remove it from the trunk on 01/jun/2013. Cheers and please comment.

7 7

Re: [webkit-efl] Common ref and unref functions for EFL WK2 objects
by Byung-Woo Lee 30 Oct '12

30 Oct '12

I also think that the basic idea is nice, but I have simple question about the implementation. > typedef Ewk_Ref_Counted Ewk_Back_Forward_List_Item; I think that, this will be in ewk_back_forward_list.h header file. and the header file will be used in the ewk_back_forward_list.cpp with ewk_back_forward_list_private.h file which has Ewk_Back_Forward_List_Item as class. Is there any problem on this? (I think there can be some compile error) Byungwoo. ------- Original Message ------- Sender : Gyuyoung Kim<gyuyoung(a)gmail.com> Date : 2012-10-30 21:37 (GMT+09:00) Title : Re: [webkit-efl] Common ref and unref functions for EFL WK2 objects Though I still need to see this patches, your work looks good to me. If there is any problems when our internal source uses this new struct or problems occur, I will let you guys know that. Gyuyoung. On Tue, Oct 30, 2012 at 9:00 PM, Kangil Han <kangil.han(a)samsung.com> wrote: Hi Mikhail, > BTW, WK2 C API has geneiric ref/unfer functions and GTK also does. Would you please let us know more specific information on this, i.e. wiki url or something that help our understanding? Kind regards, Kangil Han -----Original Message----- From: webkit-efl-bounces(a)lists.webkit.org [mailto:webkit-efl-bounces@lists.webkit.org] On Behalf Of Pozdnyakov, Mikhail Sent: Tuesday, October 30, 2012 7:05 PM To: webkit-efl(a)lists.webkit.org Subject: [webkit-efl] Common ref and unref functions for EFL WK2 objects Hi, I've already mentioned the proposal at http://lists.webkit.org/pipermail/webkit-efl/2012-October/000393.html but think (and since nobody replied so far) it deserves new topic and new thread, so duplicating proposal again here. As all the ref-counting EWK classes are inherited from WTF::RefCounted it is possible now to have generic REF/UNREF functions in the public API instead of having separate pair of such functions for every object. To say in more details we could introduce struct Ewk_Ref_Counted Ewk_Ref_Counted; and following generic functions: EAPI Ewk_Ref_Counted* ewk_ref(Ewk_Ref_Counted*); EAPI ewk_unref(Ewk_Ref_Counted*); then Ewk_Back_Forward_List_Item might be declared for instance as typedef Ewk_Ref_Counted Ewk_Back_Forward_List_Item; so that it's clear that Ewk_Back_Forward_List_Item is ref-countable (or we could just mention in docs that given object is ref counted). Would like to hear your opinion about this proposal. BTW, WK2 C API has geneiric ref/unfer functions and GTK also does. 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. _______________________________________________ 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

1 0

Encapsulation of ref counting in EWK classes (WK2 EFL)
by Pozdnyakov, Mikhail 29 Oct '12

29 Oct '12

Hi all, The idea is that EWK internal structures (those which use ref counting) can be inherited from WTF::RefCounted class, It gives following benefits: 1) Ref counting code is encapsulated and not copy/pasted between EWK structures. 2) It is possible to use internally RefPtr and PassRefPtr smart pointers which also saves a lot of lines of code Here you can see an example http://trac.webkit.org/changeset/131298 of the described approach applied. There is also a meta bug https://bugs.webkit.org/show_bug.cgi?id=99321 for gradual refactoring of all of the EWK classes. If someone is volunteering to modify a certain EWK class accordingly to the described approach please put your bug as a dependency for the meta bug. 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.

1 1

FW: Use of pimpl idiom for Ewk classes
by Kangil Han 19 Oct '12

19 Oct '12

From: Kangil Han [mailto:kangil.han@samsung.com] Sent: Friday, October 19, 2012 5:50 PM To: 'Dumez, Christophe'; 'Thiago Marcos P. Santos' Cc: 'webkit-efl(a)lists.webkit.org'; 'Kenneth R Christiansen' Subject: RE: [webkit-efl] Use of pimpl idiom for Ewk classes Hi Chris, FOA, thank you, of course including Mikhail, for the constructive discussion. :) My two cents heads to https://bugs.webkit.org/attachment.cgi?id=169425 <https://bugs.webkit.org/attachment.cgi?id=169425&action=prettypatch> &action=prettypatch No macro and so pretty! > One possible issue that I noticed with this approach is that we need to use "const char*" instead of "String" type in our C++ methods API due to Eina string sharing. This is a bit unfortunate since C++ code uses String type in WebKit. Btw, what does this mean? Would you please give us an example code? Kind regards, Kangil From: webkit-efl-bounces(a)lists.webkit.org [mailto:webkit-efl-bounces@lists.webkit.org] On Behalf Of Dumez, Christophe Sent: Friday, October 19, 2012 1:28 AM To: Thiago Marcos P. Santos Cc: webkit-efl(a)lists.webkit.org; Kenneth R Christiansen Subject: Re: [webkit-efl] Use of pimpl idiom for Ewk classes Hi, I have updated the Ewk_Download class based on the alternative mentioned by Thiago and updated a patch here for comparison: https://bugs.webkit.org/attachment.cgi?id=169425 <https://bugs.webkit.org/attachment.cgi?id=169425&action=prettypatch> &action=prettypatch (pimpl patch is still at https://bugs.webkit.org/attachment.cgi?id=169402 <https://bugs.webkit.org/attachment.cgi?id=169402&action=prettypatch> &action=prettypatch) One possible issue that I noticed with this approach is that we need to use "const char*" instead of "String" type in our C++ methods API due to Eina string sharing. This is a bit unfortunate since C++ code uses String type in WebKit. As I said in my previous email, we also need to write a lot more C++ methods than with the pimpl approach. It will be a lot more work to refactor all Ewk classes. This approach however has the benefit of being of simpler design (no macros, C++ methods can access members directly without dereferencing a pointer). I'm personally open to both approaches so I'd like to hear others' opinion. Kr, -- Christophe Dumez Linux Software Engineer, PhD Intel Finland Oy - Open Source Technology Center

3 7

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