[bt-devel] QtWebKit DOM access

[Martin Gruner]

Gary,

wow! This is exciting!

Now we need to make the quick decision if we want to hold up your changes and release a 1.7 first, or not. It seems that we do have at least one issue (bookshelf manager threading problems) that might be holding up 1.7 too, so that your changes could be made in parallel. How much time do you need to complete the KHTML->WebKit transition?
How much time would you need to eliminate the rest of the KDE dependencies left over?

Based on your answers to these questions, I'd like to hear everyone's opinions about if 1.7 should be released _before_ or _after_ these changes.

Atm I have a slight preference for releasing 1.7 _before_, but that depends on how much time Eeli will need to find and fix the threading problems.

mg


P.S. Congratulations to your successful family expansion!


am Montag, 12. Januar 2009 um 03:39 schrieben Sie:

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


> _______________________________________________
> bt-devel mailing list
> bt-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/bt-devel



-- 
Mit freundlichen Grüßen
Martin Gruner
mailto:mg.pub at gmx.net