[bt-devel] QtWebKit DOM access

[Martin Gruner]

Gary,

good! I agree with all you said.

mg

Am Montag 12 Januar 2009 14:10:08 schrieb Gary Holmlund:
> Martin,
>
> This could take another 2 or 3 weeks to finish and could introduce new
> instabilities. There are still quite a few other KDE to Qt issues. I
> have not counted all of them.
>
> It seems that we are close to getting a good stable 1.7 release out and
> I would suggest continuing on this plan. I have written the changes with
> #if such that I can check in code that works 100% like the current KHTML
> version and the new changes are not compiled into the program. This
> would allow me to use version control (and not loose anything) and make
> progress on the new code.
>
> Gary
>
> Martin Gruner wrote:
> > 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-previ
> >>>>ew/
> >>>>
> >>>>
> >>>>
> >>>> 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
>
> _______________________________________________
> bt-devel mailing list
> bt-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/bt-devel