[Development] Assistant WebKit/WebEngine support

[Eike Ziller]

> On Jun 24, 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.

PDFs (and things) can be opened in external applications which then can provide whatever other related features the user might want. We really need something that can properly render HTML + CSS + images.

> Not having a fully working engine will always lead to issues where this causes lots of additional work in other places, e.g. for the documentation team that has to tweak the content of our qch files. Currently our inline docs in Creator look a lot worse than the web version and lack many features that we have on the web based docs. How come we accept that?

Using QtWebEngine for that means that 30-40% of Qt Creator is just for viewing help. And 70% or so of that actually would actually not be required for rendering beautiful help pages like in a browser (QtWebKit was ~40 MB back in the days, and was technically already more than needed).

> We do want integrated help and we want it to look good. That means we have to simply accept the fact that we’ll need an integrated browser.

What is the state of QtWebKit(2) ? Do we have that on CI ? Can we have an export?

> Cheers,
> Lars

-- 
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
eike.ziller at qt.io
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B