[webkit-dev] Clipboard class plans

[Darin Adler]

Hi folks.

I have some work planned on the DOM clipboard classes. I’m not in a big hurry to get this done fast. It’s my side project. But I thought some people might be interested in what I am thinking about doing. I have a good 20% of the project already sitting in my local git repository and I’m going to file a bug or two and start posting patches soon.

The major step is to refactor so that Pasteboard is the platform abstraction and Clipboard is a pure DOM class built on top of Pasteboard. To do a good job on that I will probably need help from people willing to tackle platforms other than Mac. I’ve started by doing the refactoring on Mac and putting an #ifdef in place for scaffolding.

Here are my notes so far on what I think I’d like to do, in case you’d like to comment.

DOM Clipboard class and platform directory clipboard and drag abstraction class (Pasteboard)

Get Clipboard.h and DragState.h includes out of commonly-included headers.
- Doing this first makes the changes to Clipboard.h require a lot less recompiling.

Change DragClient so it uses a Pasteboard object instead of a Clipboard object to pass the identifier of the pasteboard.

Make Clipboard a non-polymorphic class with the abstractions in the Pasteboard class.
- Each Clipboard will hold a Pasteboard.
- Mac first, then each other platform.
- Share as much code as possible between platforms in Clipboard; platform differences should be primarily in Pasteboard.
- This will add more functions to the Pasteboard class.

Make Pasteboard functions const, since Pasteboard identifies a pasteboard--the actual pasteboard contents are "outside the class".
Pass pasteboards around as const Pasteboard&.

For operations that are not part of the Clipboard DOM API, have callers get to the Pasteboard and use it, rather than using the Clipboard.

Move all Clipboard class code into the DOM directory.
- Even platform-specific functions should be there, not in the platform directory.

Factor out the non-platform-abstraction parts of Pasteboard that depend on the DOM, Page, Frame, etc. and move that part into the editing directory

Move the Mac-specific snapshotting functions out of Frame.h and FrameMac.mm into their own home.
- Probably the editing directory.
- Change interfaces to be platform independent so the callers don't need to use Objective-C++.
- Consider making them cross-platform.

Investigate replacing DragImageRef with a more solid abstraction rather than a typedef.
- Need to be able to write platform-independent drag code.

Change Clipboard functions to match DOM instead of having subtly different names.

Eliminate custom bindings for Clipboard.
- Move setDragImage element logic out of JSClipboardCustom.cpp bindings into the Clipboard class.
- Change return type of Clipboard::types to PassRefPtr<DOMStringList> instead of ListHashSet<String> because that's what we support for DOMString[] in our IDL. Or alternatively, do more overloads for toArray so we can use Vector<String> or ListHashSet<String>.

Make sure Pasteboard checks this is still the current pasteboard when doing write operations with change count on Mac.
- Is there an equivalent on other platforms?
- Creating a new pasteboard gets the change count each time, which may be excessive; is there a better way to fit this in?

Put more of the dragging code inside #if ENABLE(DRAG_SUPPORT).
- It seems kind of random what is conditional and what is not.

Do something to more clearly separate the dragging and copy/paste code the Pasteboard class.

Reduce some of the strange idioms in the Clipboard class
- The use of the magic string "initialized" for dropEffect and effectAllowed is strange.

Rename Clipboard to DOMClipboard.
Rename Pasteboard to Clipboard.
Rename DragState members to eliminate the m_ prefix since it's a struct. Or make it a class.
Rename DragState::m_dragSrc to dragSource, or perhaps something even nicer.

DOM Event classes

Break headers back up into a file per class?
- MouseEvent.h has many classes in it.

Cut down on DOM event class constructors and "create" functions.
- Should need only one constructor per class, the one that takes the initializer, or possibly the empty one.
- Code inside WebCore and WebKit should use one of the two create functions used by the bindings.
- Need to put all the arguments into the initializers, but the way they work we can't put RefPtr<Clipboard> into an initializer without including "Clipboard.h"; might mean we should move initializers into separate headers.

EventInit structures called "initializers" may need some naming work.
- Better to have a name without the abbreviation "init".
- Not sure we should call them "initializers" since they are just initialization arguments; the name implies they do more than they do.

Reduce or eliminate POINTER_LOCK conditionals in MouseEvent.h.
- First, not sure it makes sense to have more state in the DOM mouse event for that feature.
- Second, if we do it's excessive to do it with ifdefs in the arguments for constructors.
- Above refactoring of initializers could be a big help here.

-- Darin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130206/79f09ef4/attachment.html>