Bug 21250 - Rename updateContents to repaintContentRectangle and make it cross-platform
Summary: Rename updateContents to repaintContentRectangle and make it cross-platform
Alias: None
Product: WebKit
Classification: Unclassified
Component: Platform (show other bugs)
Version: 528+ (Nightly build)
Hardware: Macintosh OS X 10.5
: P2 Normal
Assignee: Dave Hyatt
Depends on:
Blocks: 21083
  Show dependency treegraph
Reported: 2008-09-30 12:52 PDT by Dave Hyatt
Modified: 2008-09-30 13:11 PDT (History)
1 user (show)

See Also:

Patch (24.70 KB, patch)
2008-09-30 12:56 PDT, Dave Hyatt
darin: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dave Hyatt 2008-09-30 12:52:32 PDT
Rename updateContents to repaintContentRectangle and make it cross-platform
Comment 1 Dave Hyatt 2008-09-30 12:56:34 PDT
Created attachment 23949 [details]
Comment 2 Darin Adler 2008-09-30 13:01:13 PDT
Comment on attachment 23949 [details]

I don't understand why Chrome is derived from HostWindow. That doesn't make sense to me. I could see why Chrome would *have* a HostWindow* stored in it, but it seems really strange to derive it from HostWindow. Maybe the right thing would be private inheritance? Adding these new virtual functions to Chrome makes it harder to understand the purpose of the Chrome class.

This new window-repaint-related stuff seems way too low level to me to be a good addition to ChromeClient, but I guess it already had all this "backing store" stuff in it.

Comment 3 Dave Hyatt 2008-09-30 13:05:51 PDT

The point is to allow ScrollView to communiate via an interface in the *platform* layer, even though what really has to happen is that the interface calls out (over in the page layer).

HostWindow <-> Chrome is basically analogous to:

ScrollView <-> FrameView

Right now ScrollView violates the platform/ layer abstraction all over the place by casting itself to FrameView and manually grabbing the ChromeClient.  This new HostWindow object will enable ScrollView to remain a platform/ abstraction.

It may be that there should be a ChromeWindow and ChromeWindowClient instead of a Chrome and ChromeClient, but looking at Chrome, the majority of functions defined on it are window-related.

One final point: the number of functions defined on Chrome should actually *shrink* by the time I'm done with this refactoring, since all of those backing store functions are going to go away (and/or be replaced).

Comment 4 Dave Hyatt 2008-09-30 13:11:31 PDT
Fixed in r37105