[Development] Assistant WebKit/WebEngine support
lars.knoll at qt.io
Mon Jun 24 22:44:24 CEST 2019
> 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.
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?
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.
More information about the Development