[webkit-dev] Clipboard class plans

[Daniel Cheng]

I can help with work required for the chromium port.

On Wed, Feb 6, 2013 at 9:13 AM, Darin Adler <darin at apple.com> wrote:

> 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>.
>

​I think ​Clipboard.types currently returns an Array. There's a patch in
progress to change this to Vector<String> to remove the need for custom
bindings (https://bugs.webkit.org/show_bug.cgi?id=82878 and
https://bugs.webkit.org/show_bug.cgi?id=82888). The spec originally
specified DOMStringList, but this ended up being changed, since
DOMStringList is considered deprecated.


>
> 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?
>

​Windows has GetClipboardSequenceNumber(); however, Linux has nothing
comparable "built-in". There are some things like QtClipboard and XFixes
that provide a pasteboard changed event that ​add this functionality.



> - 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
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130206/2fd06aa6/attachment.html>