Move clipboard-related webkit_glue embedder functions into a ClipboardClient interface.

webkit/glue/scoped_clipboard_writer_glue.cc

Index: webkit/glue/scoped_clipboard_writer_glue.cc
diff --git a/webkit/glue/scoped_clipboard_writer_glue.cc b/webkit/glue/scoped_clipboard_writer_glue.cc
new file mode 100644
index 0000000000000000000000000000000000000000..1938c76628c3b5e9ecbc926fe2b262857934832c
--- /dev/null
+++ b/webkit/glue/scoped_clipboard_writer_glue.cc
@@ -0,0 +1,20 @@
+#include "webkit/glue/scoped_clipboard_writer_glue.h"
+
+ScopedClipboardWriterGlue::ScopedClipboardWriterGlue(
+    webkit_glue::ClipboardClient* client)

[Dirk Pranke, 2011/11/21 20:00:54]

I realize this is the pre-existing design, but I'm a little fuzzy on why we have
both the context and the client. I'm wondering if we can simplify this now that
we have a proper clipboardclient interface. That could be done as a separate
change, though.

[piman, 2011/11/21 20:27:14]

There is a single client per webkit instance (i.e. essentially 1 per process),
but you need one "context" per ScopedClipboardWriterGlue, which is where you can
store per-write & per-client data.
I agree that the code is a bit awkward in the combination of this and
ScopedClipboardWriter. What is needed I think for a clean design is to separate
the "gather data and format it" part from the "write it" part from the "scoped"
part.

+    : ui::ScopedClipboardWriter(client->GetClipboard()),
+      context_(client->CreateWriteContext()) {
+}
+
+ScopedClipboardWriterGlue::~ScopedClipboardWriterGlue() {
+  if (context_)
+    context_->FlushAndDestroy(objects_);
+}
+void ScopedClipboardWriterGlue::WriteBitmapFromPixels(const void* pixels,
+                                                      const gfx::Size& size) {
+  if (context_) {
+    context_->WriteBitmapFromPixels(&objects_, pixels, size);
+  } else {
+    ScopedClipboardWriter::WriteBitmapFromPixels(pixels, size);
+  }
+}