[Webkit-unassigned] [Bug 84933] [EFL] scrolling with fixed position does not work correctly when using ewk_view_tiled.

[bugzilla-daemon at webkit.org]

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





--- Comment #6 from KwangHyuk <hyuki.kim at samsung.com>  2012-05-10 00:28:15 PST ---
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > If you want to use it only for ewk_view_tiled,
> > > What do you think about just adding EWK_VIEW_TYPE_CHECK_OR_RETURN in ewk_view_scroll_offset_update
> > > like ewk_view_frame_view_creation_notify?
> > Yes, I agree that it should not be in public API. But current architecture doesn't allow solve this issue in proper way. Moreover, IMO any implementation that is in ewk_view.cpp file should be generic for all view type. I think it should be not allowed to put specific single/tiled view implementation in this file. For example it is not good to have ewk_view_frame_view_creation_notify implementation in ewk_view file and IMO it should be removed from there. I know the way that you proposed is simple but we need something what will simulate "protected" scope from C++ language. For example pointers to function that should not be in public API (not in _Ewk_View_Smart_Class) should be placed in new _Ewk_View_Private_Smart_Class structure in ewk_view_private.h file. This will solve this and similar issue (like ewk_view_frame_view_creation_notify)
> 
> I also agree that it is not cool.
> But, I am now thinking that changing API for the internal requirements is worse
> and introducing additional structure for few function of ewk_view_tiled is over-implementation.
> 
> I want to listen more opinion for this.
> 
> Thanks.

IMO, using smart change api for the object would be possible. :)

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