I can help with work required for the chromium port. On Wed, Feb 6, 2013 at 9:13 AM, Darin Adler <da...@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@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev