View Single Post
Old 06-18-2019, 10:59 AM   #12
KevinH
Sigil Developer
KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.
 
Posts: 8,859
Karma: 6120478
Join Date: Nov 2009
Device: many
I am sure you are aware of most of the following but I was not ...

The asynchronous nature of QtWebEngine is way way too understated in the official docs. For example loading (as before), getting plain text or html (as documented), running javascripts (documented) are asynchronous but so are rendering (comes after loading with no signal to say rendering is complete!), grabbing focus (especially in headless mode but no signal to say you have focus), text selection (but at least there is a signal) and etc are all asynchronous and can cause issues depending on your design.

In fact, I have run into many issues due to the lack of signals when trying to run in headless mode just to use a webview to extract text from an element or an entire page due to lack of signals (see QTBUG-75505).

Then there is the need to override the acceptNavigationRequest in QWebEnginePage to handle links pressed but the underlying model has already generated the loadStarted() signal (BEFORE acceptNavigationRequest has returned!) and if you decide to handle a specific link type and return (false for it) the engine later generates a loadFinished(false) even though no load was ever done. (See QTBUG-75185)

The false loadStarted() and loadFinished(false) can interfere with loading and running javascripts as well. I had to add state variables to determine if and when it was perfectly safe to inject/run javascript tracking all load started and loadFinished.

Then there is api documented mouse, and key event handling routines that simply do NOT work (they are never invoked) as many of the user based events are handled by a delegate. So you have to add an event listener at the start and then look for new delegate being added to the QWebPageEngine and then installing listeners on them as they are handled. I still have not figured out why these delegates die and go away (seemingly at random at times).

With the lack of signals for getting focus, rendering, etc, you really have to just hope that the user waits for the window to actually render before trying stuff. In fact, the whole design (when no required signals are provided) actually is very racey and I am not a fan of it.

I think they should have designed a minimal set of signals to track at least the major states of the system including loading, focusing, and rendering to say the very least.

We are not sure how robust the Preview Window is under QWebEngine and simple editing used in our PageEdit (extracted all of BookView as it was a PITA) into a simpler QtWebEngine separate app. Hoping to release the beta in a week or two just to finally see what has to be worked on to get something stable.

All in all a good time was had by all

Last edited by KevinH; 06-18-2019 at 11:07 AM.
KevinH is offline   Reply With Quote