[Development] HTML5/CSS vs Qt QML and QtCreator / Assistant

André Pönitz apoenitz at t-online.de
Fri Jun 28 13:22:51 CEST 2019

On Fri, Jun 28, 2019 at 09:32:43AM +0000, Cristian Adam wrote:
> Hi,
> Some of you might have been familiar with white papers such as Qt QML v HTML5 –
> a practical
> comparison<http://dforeman.cs.binghamton.edu/~foreman/360new/examples/Using%20QT4/WHITEPAPER_HTML5vQML.pdf>.
> Qt Creator already ships with QML support, why not transform the HTML offline
> documentation into QML?

I don't believe does can address the display problems, as I don't believe Qt
Quick's TextArea is even on par with QTextBrowser. But I readily admit that my
knowledge here is outdated: the last time I seriously looked at TextArea was
when the 16384 char limit was about to be addressed.

>  Does it have to be HTML5/CSS?

No, but I don't think Qt Quick provides any advantages in this case.

HTML + CSS is fine in principle, and widely used, and with a *light weight*
rendering engine that does not even have to support *full* HTML5 + *full* CSS
that is a good solution.
> Having the documentation as QML will have no additional constrains for Qt
> Creator.

Not in principle, as the pre-built Qt Creator binaries depend on Qt Quick already
but one of the reasons to replace the Qt Quick based Welcome plugin by a widget,
based one was that users repeatedly run into problems with it, even in rather
normal setups, and we were getting tired of recommending  -noload Welcome  as a
the default workaround.

Now, Help is not *that* prominent as the Welcome screen, in the sense that it does
take one more click to get there, but right now I am not fancying to recommend
-noload Help  as a "solution" for anything ;-)

> QML is supported on all platforms, right? Builds with MinGW on Windows, and so
> on.

Yes, but it has limitations, too, and really offers no advantage over QTextBrowser
that I am aware of. So this effectively would just change the set of affected
people. I.e. MinGW users might get it in principle now, compared to a WebEngine
based solution if I get the right, on the other hand the previous  -noload Welcome
audience will be left out.

I still favour solutions that do not lock out anyone.


More information about the Development mailing list