[Development] Assistant WebKit/WebEngine support

[Kirill Burtsev]

Hello,

That for sure doesn't account for complexity of what we are getting with this move. Quite heavily stripped down version of chromium inside webengine has ~20M loc, that is 10x times more than whole qtc. The actual browser is twice as big in terms of loc. Official doc page for building Qt suggests to skip webengine. Number of supported compilers and environments is also limited. MSYS2 environment has latest mingw and clang, and this environment is sufficient to build whole Qt (and libraries are there except, of course, webengine). WebEngine doesn't only display fancy looking htmls with styles, it is almost full-blown browser. Why is it needed this way in ide?

Qt Creator is not a light-weight ide already. Popularity of editors-ides like vscode, sublime, vim/emacs-based envs clearly shows how important this factor is. Will it run fine on 5-6 years old laptops or on recent phones and tables with desktop features and arm cpus?

I don't think that a lot of developers really care about how wonderful help module looks like as long as it answers development related questions clearly and precisely. Nowadays help/doc search activities is much more than just open offline page with descriptions of classes and methods with examples. We search through QA web sites and dev forums, tutorials and videos, source repositories, social discussion platform. Why not to delegate all those activities to proper browser environment of choice with all its extensions and custom setups? And just improve query part of qtc help (index, content seaches) to speed up simple Qt and c++ related queries and fall back to proper web search engines outside of ide for anything more complex. Embedding browser into ide seems to me like a huge misdirection.


________________________________
From: Development <development-bounces at qt-project.org> on behalf of Simon Hausmann <Simon.Hausmann at qt.io>
Sent: Monday, June 24, 2019 14:43
To: development at qt-project.org
Subject: Re: [Development] Assistant WebKit/WebEngine support


Am 24.06.19 um 12:31 schrieb Eike Ziller:
>> * What exactly is so big about WebEngine? What is this size that many are hinting at but won't provide the number?
> My numbers on macOS:
>
> WebEngineCore.framework = 145 MB
> Current Qt Creator application = 430 MB (and about 60 MB of this we currently try to get rid off again because it’s actually duplicate binary code)


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.


Simon

_______________________________________________
Development mailing list
Development at qt-project.org
https://lists.qt-project.org/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190625/5bade664/attachment.html>