[Development] Assistant WebKit/WebEngine support

Morten Sørvig Morten.Sorvig at qt.io
Tue Jun 25 10:10:44 CEST 2019


> On 24 Jun 2019, at 22:44, Lars Knoll <lars.knoll at qt.io> wrote:
> 
> 
>> On 24 Jun 2019, at 21:54, Tor Arne Vestbø <Tor.arne.Vestbo at qt.io> wrote:
>> 
>> 
>> 
>>> On 24 Jun 2019, at 14:43, Simon Hausmann <Simon.Hausmann at qt.io> wrote:
>>> 
>>> I have two more numbers to add: Compressed (7z) the download size would 
>>> be around ~44 MB. I measured on Windows with a Qt Creator built with 
>>> WebEngine support and surfed a little through the docs. The memory 
>>> consumption of the web engine process weighed in between 14-20 MB of RAM.
>>> 
>>> So it looks like this AFAICS:
>>> 
>>>   * We would be adding 145 MB of additional disk usage
>>> 
>>>   * We would add ~44 MB to the download size of Qt Creator
>>> 
>>>   * We would eat ~14-20 MB of additional RAM (not quite fair though, 
>>> as we'd have to subtract the QTextDocument memory usage for a diff).
>>> 
>>> 
>>> I don't quite share the opinion that these are "beastly" numbers for 
>>> desktop machines running C++ development environments. I think that they 
>>> are worth it. In exchange we can show external content like cppreference 
>>> or cmake docs without having to worry about their rendering, we can get 
>>> rid of our separate style sheets and workarounds and we can render the 
>>> Qt documentation the same way as on the website. We can eliminate an 
>>> entire class of problems, and we can still prevent such content from 
>>> accessing remote websites.
>>> 
>>> 
>>> We've had this situation for a long time now and I think that we should 
>>> finally move forward and give our users better quality at the expense of 
>>> their disk space, memory consumption and download size.
>>> 
>> 
>> I fully agree with this. Thanks for the numbers Simon!
> 
> Another +1 from me. Let’s stop fighting this. We need something that can properly display any HTML content (and maybe PDF and things as well) that we throw at it.
> 

I’m not sure if it has been mentioned; we have another option which is to use the OS web browser component via the Qt WebView module.

The benefits would be

* up-to-date web browser (and someone else keeps it up to date for us)
* insignificant additional download size
* no trouble with restricted platforms where shipping a full web browser is not feasible (but then maybe creator isn’t going to run on those platforms, anyway)

QWebView’s platform coverage may be insufficient for Creator, which means

* no html docs on those platforms :(
* or, we expand QWebView platform coverage
* or, QT WebView does have a WebEngine backend

Cheers,
Morten









More information about the Development mailing list