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
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
