[bt-devel] QtWebKit DOM access

[Gary Holmlund]

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

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.

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.

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.

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.

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.

Gary Holmlund


Eeli Kaikkonen wrote:
> Martin Gruner wrote:
>   
>> Hi all,
>>
>>
>> there seems to be a way to access the DOM even without direct QT interfaces. 
>>
>> Please see: http://labs.trolltech.com/blogs/2008/11/04/search-with-thumbnail-preview/
>>
>> Is this something we could use or should we wait?
>>   
>>     
>
> It's not immediately clear how that works. We should research this. IMO 
> our current way is not the only right one; anything which works well is 
> good. If it can be written with small amount of code and the runtime 
> performance is good then it's worth implementing. But it depends also on 
> the future of the Qt API. They may add DOM access to some future minor 
> version. Should we ask somewhere if there are any real plans for that?
>
> --Eeli Kaikkonen
>
> _______________________________________________
> bt-devel mailing list
> bt-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/bt-devel
>