[webkit-efl] Few change suggestions in EFL port

Thiago Marcos P. Santos tmpsantos at gmail.com
Fri Apr 20 04:19:41 PDT 2012


Hi,

Tomasz made a excellent point here. I agree from 1 to 6.

Everything on a single private header will not scale on the long run. I
vote for splitting into different files for the sake of code readability.

Putting more emphasis on 6): what needs to be EFLish is only the public
API we are exposing to the users. For all the rest we should favor the
WebKit best practices. This will make reviewers life easier as mentioned.

New API's are coming, it's better decide on this ASAP. For the things that
are already on ewk_private.h, we can create a master bug to track the
refactoring. The good thing about this change is it should be seamless to
users of the public API.

Cheers,

On Fri, Apr 20, 2012 at 10:59 AM, Tomasz Morawski <t.morawski at samsung.com>wrote:

> Hello,
> I would like to ask if anyone have some comment about this topic?
>
> Thank you,
> Tomasz Morawski
>
>
>  Hello,
>> I would like to propose changes related to some aspect of c programming
>> style used in our EFL WebKit port that could make our port more
>> consistent with other WebKit port like Gtk and Qt. Currently, we are
>> trying to follow some EFL libraries programming style that hides
>> structures declaration inside cpp files and use one single private
>> header file. I know that it works inside EFL's libraries but the our
>> WebKit port it is not and it will never be typical EFL's library. I
>> think current solution doesn't work well for example: overgrown files
>> like ewk_view.h/cpp, ewk_frame.h/cpp files and ewk_private.h file, a lot
>> of unneeded public API that is used only by internal WebKit tools (like
>> DRT) but it will be never uses by final user. Moreover, there is a lot
>> of programmers that would like to cleanup this mess and have more
>> readable port architecture.
>>
>> I suggest to:
>> 1) Allow to define ewk_*_private.h files when it is needed and use it
>> internally like Gtk, Qt port does. It is possible to use ewk_*_private.h
>> files by internal test application: the DRT tree or
>> other tests.
>>
>> 2) Move structures form cpp files to corresponding private header files
>> (approach like Gtk and typical for c programming)
>>
>> 3) Move private function from ewk_private.h to corresponding private
>> header files and delete this file (more objective)
>>
>> After that:
>> 4) Simplify and remove some code that will be no need after this
>> refactor (some code is only for handling private by force structures).
>>
>> 5) Reduce size of ewk_frame.h/cpp and ewk_view.h/cpp files by moving
>> some declaration to ewk_*_private.h
>>
>> 6) We will follow typical for WebKit's port architecture like qt, gtk
>> port do (they use private file widely). Due to that the port code
>> organization will be more familiar for gtk reviewers and newcomer
>> programmer.
>>
>> What you think about this?
>>
>> Best Regards,
>> Tomasz Morawski
>> ______________________________**_________________
>> webkit-efl mailing list
>> webkit-efl at lists.webkit.org
>> http://lists.webkit.org/**mailman/listinfo.cgi/webkit-**efl<http://lists.webkit.org/mailman/listinfo.cgi/webkit-efl>
>>
>>
> ______________________________**_________________
> webkit-efl mailing list
> webkit-efl at lists.webkit.org
> http://lists.webkit.org/**mailman/listinfo.cgi/webkit-**efl<http://lists.webkit.org/mailman/listinfo.cgi/webkit-efl>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-efl/attachments/20120420/796d51eb/attachment.html>


More information about the webkit-efl mailing list