Yes, we need to support both qtwebkit and qtwebengine in 2.6, though the "only" big platform without qtwebengine is now debian/ubuntu after fedora found a way to get it in fedora 24: fedoraproject.org/wiki/Changes/QtWebEngine
Den fre., feb. 19, 2016 kl. 20:22 skrev Jonathan Springer<[email protected]>: I think, from the previous conversations here on the mailing list, the issue with going to only QWebEngine is that it may not be available on all platforms due to licensing issues. On Fri, Feb 19, 2016, 1:49 PM Tim and Alison Bentley <[email protected]> wrote: Ok do we need to support old webkit and new webkit at the same time or wth openlp 2.6 we will be in a qwebengine world.Thinks about backward OS's like Mac! On 19 February 2016 at 18:37, Jonathan Springer <[email protected]> wrote: The main issue we have is that several of our methods depend on the javascript call being synchronous which is no longer the case as QWebEngine is entirely asynchronous and requires a call back to return information. Thus the need to make our functions/API asynchronous. On Fri, Feb 19, 2016 at 1:33 PM Tim and Alison Bentley <[email protected]> wrote: this article makes it look much simplar or have it missed somthing. https://wiki.qt.io/Porting_from_QtWebKit_to_QtWebEngine On 19 February 2016 at 18:27, Jonathan Springer <[email protected]> wrote: Here are my thoughts and findings so far regarding the migration to QWebEngine. There is a card on our Trello board that is tracking the progress of this migration and will be updated as work progresses. The following steps are what I think should be done and the order they should be done in. - Move all functions that need access to DOM into javascript - Make all calls to renderer asynchronous - Make minimum Qt version Qt 5.4 (QWebChannel dependency) - Use QWebChannel to access javascript functions and receive callbacks - Create backend class to handle switching between available backends - Create QWebEngine backend - Move existing QWebKit implementation into a backend Moving DOM access into javascript shouldn't be to hard. Making all calls to the render asynchronous is a bit harder and is making my brain hurt trying to figure out how to do it since our current API is synchronous. Note: We cannot just use a while block since that blocks the UI thread which also blocks Qt's event system preventing QWebKit/QWebEngine from doing anything. We can use a processEvents() call in the while loop but that is frowned upon. Once we make all calls asynchronous the remaining items should be pretty easy to do. I would recommend getting the first four items (DOM access into javascript, asynchronous calls, minimum version, and QWebChannel) working with QWebKit first then move on to the rest. _______________________________________________ openlp-dev mailing list [email protected] https://lists.openlp.io/mailman/listinfo/openlp-dev -- Tim and Alison Bentley [email protected]_______________________________________________ openlp-dev mailing list [email protected] https://lists.openlp.io/mailman/listinfo/openlp-dev _______________________________________________ openlp-dev mailing list [email protected] https://lists.openlp.io/mailman/listinfo/openlp-dev -- Tim and Alison Bentley [email protected]_______________________________________________ openlp-dev mailing list [email protected] https://lists.openlp.io/mailman/listinfo/openlp-dev _______________________________________________ openlp-dev mailing list [email protected] https://lists.openlp.io/mailman/listinfo/openlp-dev
_______________________________________________ openlp-dev mailing list [email protected] https://lists.openlp.io/mailman/listinfo/openlp-dev
