[webkit-efl] Few change suggestions in EFL port

[Tomasz Morawski]

Hi,
Master bug for this change: https://bugs.webkit.org/show_bug.cgi?id=84572

Best Regards,
Tomasz Morawski

> 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 <mailto: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 <mailto: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 <mailto:webkit-efl at lists.webkit.org>
>     http://lists.webkit.org/__mailman/listinfo.cgi/webkit-__efl
>     <http://lists.webkit.org/mailman/listinfo.cgi/webkit-efl>
>
>