[Qt-interest] QWebView for document editing

Sat Jul 11 15:50:30 CEST 2009

On Jul 11, 2009, at 7:48 AM, Gav Wood wrote:

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

I'm working on a project that is doing this exact thing.

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

What we do is as we generate the HTML from our model, we wrap those  
blocks that we want to label in things of this form:

	<span id="our special id here"> ...actual content... </span>

(or you could use div or whatever's appropriate).  This flags your  
document with the points in your model that it represents.  So when  
you get a hit in the web view, you can walk up the DOM tree to find  
the first relevant span, get its id, and use it.  I won't describe  
that Javascript here, since I'm assuming you could build it, but if  
you want to see it, lemme know and I'll paste our code in.  It's not  
long.

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

Javascript in the web view can get this information for you.  Google  
stuff like offsetLeft, offsetWidth, etc. as HTMLElement properties.  I  
haven't used this myself, I just know it exists.  You have to be  
careful with taking scrolling into account, too.

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

Hah.  We do this same thing. :)  Override the ::event() method in a  
subclass of the webview and filter out the keypresses you don't want  
the web view to see.

Furthermore, you can modify the HTML for just one element using  
Javascript in the web view also.  myDocElement.innerHTML = 'html code  
here';

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

You came to the right place!  Lemme know if this doesn't work for you.

Nathan