[bt-devel] QtWebKit DOM access

[Eeli Kaikkonen]

Quoting Gary Holmlund <gary.holmlund at gmail.com>:

> Hello,
>
> I am back after a nice vacation in France with my son, daughter-in-law,
> and new grand-daughter. I had some spare time and took my laptop, so I
> decided to research the QtWebKit DOM issue.

Great to hear good news from several frontiers. Welcome back.

>
> So, starting in chtmlreaddisplay.h/cpp, I switched the KHTML to
> QtWebKit classes. I had to comment out much of the source in
> chtmlreaddisplay.h/cpp just to get it to compile. Then comes the job of
> adding back all of the commented out functionality. As of now it does
> the following:
>

Oops, it looks like we have done duplicate work. Well, it's not
dangerous... I only created a new class, BtHtmlReadDisplay, and get it
to compile with the rest. It doesn't even show
any text yet.

> 1. Displays the html. This was trivial to connect.
>
> 2. Scrolls to the correct position based on html anchor. QtWebKit does
> not have a gotoAnchor() function like KHTML does. I had to call from
> c++ to javascript to do this.
>

I guess there must be a way to do this without javascript. After all,
going to an anchor is basic functionality of any web browser. Maybe we  
could look into the source code of the Qt example browser (I don't  
remember what it's called).

> 3. The Mag Window is working. I had to catch the mouse move event in
> Javascript, get theDOM info, and call c++ with it. The c++ calls back
> to Javascript to enable a timer. The Javascript timer event gets the
> DOM info can calls back to c++ to complete the mag window update. This
> is the same flow that the original code did and just a difference of
> where (c++ versus js) each step is done.
>

That's great, that was the most difficult part to think of in advance.

> 4. The Drag/Drop of verses to the bookmark window is working. I had to
> catch the mousemove and mousedown events in Javascript, gather the DOM
> info and call c++. The QDrag is created much like it originally was.
>

How about dropping? Does it accept dropped bookmarks/references?

> I believe this is the critical functionality to prove feasibility of
> using the current(4.4.3) QtWebKit. There are several more
> functionalities to complete and much testing to do.
>

RMB menu is the most important remaining piece.

> I arranged the code in both the chtmlreaddisplay.h/cpp files like this:
>
> #ifndef USE_QWEBKIT_CHTML
>       all of the original code ...
> #else
>       new code ...
> #endif
>
> This allows me to compile either the old or new version by the change
> of one #define. With a "diff" I can show that the original code has not
> been changed. I have also added a new Javascript file and a c++ class
> that is called from the Javascript.
>
> If you agree, I would like to check in these changes in the next few
> days and then continue to work on completing this functionality.

I would rather have a new class named BtHtmlReadDisplay. There are not
so many callers, they could have the #if clauses if necessary.

Another possibility is to create a branch. Then #ifs are not needed at
all. Something like git would be great now, but maybe we just use svn.  
It's also possible to create a branch for 1.7 because there won't be  
much changes left for that and we could backport bug fixes from the  
webkit HEAD. I also think that it's better to release 1.7 first and  
only after that move completely to WebKit based development.

--Eeli Kaikkonen