On Thu, Jun 27, 2019 at 01:47:32AM +0000, Lars Knoll wrote:
> Yes, Webengine uses some memory. But is that really a problem on
> developer machines?
On three out of four machines that I use with Qt Creator regularly
have limitations that make the presence of WebEngine undesirable.
These three might not qualify as "developer machines" for you, but I
actually use them for development.
> People propose adding functionality to QTextBrowser instead. I do not
> thing that’s a viable solution (we’ve tried that in the past and our
> technical writers hit the next issue some weeks/months later). The
> problem is not that one could not add support for one or two new
> features to QTextBrowser, it is that we do not know what features we
> will need in our docs in the future.
The current feature set is kind of sufficient to get the job done.
Nobody claims that it is perfect or even close to that. Also, my "our"
technical writers (which surprisingly seem to be different from your
"our" technical writers) hinted that the missing table borders might
actually be a recent regression in QTextBrowser.
> And that we (as Kavindra pointed out) are wasting a lot of our
> technical writers time trying to ensure the content is rendered in a
> somewhat usable way in Creator.
The time is wasted only if the result cannot be used, e.g. when one
doesn't take the target environment into account when doing the work.
If I were to design my Qt application in a way that I created GUI
elements outside the GUI thread, or wanted templates as QObjects, or
maybe needed copiable QObjects, and reported failure here I am fairly sure
the reaction would not be Deus ex Machina declaring "Let there be
threads! Let there be objects!", but rather some more or less polite but
explicit hint that this is my fault.
> This is frustrating to those people who are trying to create as good
> as possible documentation for Qt and leads to us having worse quality
> documentation than we could.
>
> Using Qt Webengine to render the docs is a rather straightforward
> and easy solution to this problem.
No. See below.
> The additional memory usage is a rather small price to pay
I'd even let that pass based on Simon's "14-20 MB RAM" number, even
in my "development" setups. Strangely enough that's not what other
people see.
> for better usability of our docs, giving our
> technical writers more options and simplifying their lives.
The "usabilty" in question here was
- table backgrounds via CSS for a submodule (which (a) would make
it inconsistent with the rest of Qt doc tables, and if I got it
right would (b) in principle be doable with QTextBrowser if done
properly)
- missing table borders, which are possibly "just" a bug.
So no. Not even with the 14-20 MB RAM price tag.
Regarding the "easy solution to this problem": You failed to address
the problem of security. The limitations of QTextBrowser are actually
a huge advantage in this area: You can't break it *that* easily.
With a full webbrowser there are essentially two basic options when
it comes to security:
1. The "always online, always update" scenario. The drawbacks here are:
- It's not how quite a few people do and want to use it
- We are simply lacking the ability to create ad-hoc releases
on short notice, leaving users vulnerable
- We will lose the currently existing ability to drop
features with high maintainance effort but small user base
by telling the remaining users to simply stick with an
older version (which works surprisingly well in practice)
2. The "cut down to the bare bones" HTML+CSS renderer to get a
similar attack surface as QTextBrowser.
- This is far from being a "full browser" anymore, some of the
claimed advantages will not be available anymore
- It takes effort to patch and maintain the patch
- It takes effort to check that the reaining code is indeed
not vulnerable. The days that Chromium downloads binary
blobs on startup might be over, but that's something to
verify on each update.
Of course there's also middleground, with a respective mixture of
drawbacks.
So which one would be exactly the one you just decreed as "easy solution"?
> Qt used to make a point on having superior documentation to most other
> frameworks,
That's still true at least for the core modules, and the point has
traditionally been made on the actual contents of the docs, not on table
borders, stuttering animations, or chunks of JaveScript trying to call
home to Google - to name just few of the advantages of the current online
help that apparently serves as benchmark here.
> and it was (and still is) one of the reasons for its success.
And, surprise!, the use of QTextBrowser wasn't a problem for this
success.
> Whatever we can do to help make the documentation better is something
> I think we should do.
When benefits outweigh costs. Not at any price.
Andre'
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
