[Qt-interest] QWebView for document editing

Gav Wood qt-interest at quidprocode.co.uk
Sat Jul 11 13:48:04 CEST 2009


Hi,

I'm trying to work out whether QWebView/QWebPage is flexible enough
for an editor I'm coding with Qt. The idea would be to transform a
heirarchically-stored model (representing the "document" currently
being edited) into HTML/CSS for display and editing with QWebView. I
am currently using a custom-coded layout system which is inflexible,
difficult to use and slow, so moving over to a standards-based system
that is fast and flexible would be a real boon.

Though I'm confident that QWebView would provide the flexibility for
the layout, I'm most concerned about user-interaction and updating:

- Hit-testing: Hittesting at the moment doesn't seem to return
anything that could be considered a genuinely unique ID (ideally a
pointer into the "document"'s model); this would be crucial. Perhaps
allowing a special attribute within any tag of "key" which is
interpreted interally as a void* and stored alongside the element as
its UID. (i.e. Given the HTML document "<body><h1
key="0xbffff18">Hello</h1></body>", if the header were clicked should
call something vaguely like: virtual void elementClicked(void* _key).)

- Decoration: Ideally I would like to paint an overlay to show
metainformation concerning the "document" (e.g. current node
selected). To do so would require knowledge of a bounding box for any
given node in my "document"'s model. Following from the previous
example, something like QRect QWebPage::boundingBox(void* _id) const;
would be good for me.

- Differential updates: Typically only a small number of nodes in the
(possibly quite complex) model will change at a given time. Ideally
the complexity of an update in the QWebPage would scale with the
number of nodes changed rather than with the size of the entire
document. Similarly rather than rebuilding an entire HTML/CSS text
document when one node in the model changes, it would be nice to
notify the QWebView of that single change. One possible way I could
see this working is if with the "contenteditable" attribute set to
true on appropriate elements in the HTML, I was able to catch and
reinterpret the key presses (and change the HTML within that element
in some arbitrary manner). Perhaps something like: virtual QString
QWebPage::documentEditStart(void* _elementKey), virtual QString
QWebPage::documentEditStop(void* _elementKey), virtual QString
QWebPage::documentEditKeyPress(void* _elementKey, QKeyPressEvent* _e).

I haven't studied QtWebKit for very long at all (a couple of hours
this morning!) so if I'm out of date or just plain wrong with my
assumptions, please accept my apologies!

Thanks,

Gav



More information about the Qt-interest-old mailing list