[Webkit-unassigned] [Bug 83007] [EFL] EFL's LayoutTestController overridePreference implementation

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=83007


Rafael Antognolli <antognolli at profusion.mobi> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |antognolli at profusion.mobi




--- Comment #6 from Rafael Antognolli <antognolli at profusion.mobi>  2012-04-11 07:47:23 PST ---
(In reply to comment #4)
> (In reply to comment #3)
> > (From update of attachment 136650 [details] [details])
> > The ewk_view_setting_{get,set}() stuff isn't very EFL-like, and is yet another place to maintain when adding/removing settings. I don't like this. 
> > 
> > One could easily write LayoutTestController::overridePreference() by calling directly the already existing ewk_view_setting family of functions, without sacrificing readability at the call site.
> > 
> > Informal r-.
> 
> Not all the necessary settings are currently present in ewk_view_setting family. 
> Keeping the old approach would require adding of 6 new functions to the ewk_view interface (for 3 new settings). Solving of https://bugs.webkit.org/show_bug.cgi?id=83687 will also require adding of 2 more functions and so on.. 
> Isn't it better to have a common setter/getter interface for all the settings?
> The whole old ewk_view_setting family could be removed and it would significantly  decrease the size of ewk_view header file and improve its readability.

Is it adding more functions for settings that bad?

If we use one function to set all the properties we are not going to reduce the amount of code, just the size of the header, but I don't think we really need that. The chromium port, as an example, has one function per setting too, similar to us.

I also don't think we should move webkit-efl exposed API away from the EFL coding style. This would just make things less consistent with the rest of the libraries.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.