You mention some refactoring.
But the thing you mention here with the biggest significance is creating a
WebKit-internal clipboard to augment the platform-specific clipboard mechanisms
that work between processes and between WebKit and non-WebKit within a process.
I think that’s OK, but it does have a significant downside. If done in the most
obvious way we will no longer have an easy way to test the system clipboard
code paths. And those are used a lot, for example to copy from Safari to Mail
on Mac OS X. I’m not sure that having duplicate code paths to optimize behavior
inside the WebKit process is worth it, but it might be a worthwhile feature.
My main advice would be to do refactoring separately from behavior changes. And
in steps that are as small as possible.
But clipboard is an area where we have some messy code so some work on it could
help. Not the work you mentioned, but some even more basic refactoring and
redesign. We have a major architecture mistake in our current Clipboard that
should be fixed.
The Clipboard object itself is a DOM object, in dom/Clipboard.idl and
dom/Clipboard.h. Unfortunately, this DOM object has platform-specific bits in
the wrong directory. They are in the platform directory instead of being in the
dom directory or per-platform dom subdirectories. The platform directory holds
a separate module, which should have no knowledge of DOM at all. It’s not
appropriate to have the platform-specific implementation of a dom class in the
platform directory.
What we need is a lower level clipboard abstraction in the platform directory
that the DOM Clipboard object can use. Think of this relationship as analogous
to the relationship of the DOM Canvas graphics context to the platform
directory GraphicsContext class. The new object should be in the platform
directory and the one in the dom directory should use it. Most platform
specifics could be factored out completely from the dom directory and the need
for per-platform source files in that directory would be minimal.
Another cross-platform clipboard abstraction is in platform/Pasteboard.h.
Unfortunately, it too does not belong in the platform directory in its current
form. It has code that deals with the DOM and editing machinery that is not
allowed in the platform module.
Straightening out these classes would be an important part of refactoring to
clean up clipboard-related code. Code to map DOM to various platform-specific
pasteboard formats belongs in the editing subdirectory in platform-specific
files so we can cope with platform-specific formats, perhaps using code from
the platform directory to help with other aspects of the platform-specific
clipboard machinery. Code to implement the DOM clipboard object should remain
in a directory other than platform, either the dom, editing, or html directory.
A platform-independent abstraction to allow these other classes to be written
cleanly with a minimum of platform-specific code should be in the platform
directory.
-- Darin
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
