[Interest] [Development] Short/medium term evolution of the Assistant?

[André Pönitz]

On Fri, Nov 10, 2017 at 11:03:46PM +0100, René J.V. Bertin wrote:
> > > are there plans to retire QtWebKit support, migrate to using QtWebEngine or
> > > to improve QTextBrowser's HTML support?
> > 
> > WebEngine is plainly inacceptable as dependency for QTextBrowser which is part
> > of the QtWidgets module.
> 
> How does my question suggest that?

My fault, I missed the "or" in your sentence - "migrate to using QtWebEngine [...]
to improve QTextBrowser's HTML support" - and that changed the meaning ;-}

> Evidently neither of the "full-fledged browser in a widget" libraries should be
> dependencies for QTB...
> 
> > This was already true for WebKit, WebEngine is even worse.
> 
> It sure is =)
> 
> > How QTextBrowser renders HTML is kind of irrelevant for how .qch files are
> > rendered, when there are other options.
> 
> Yes, as long as there are other options. WebKit is deprecated, WebEngine is
> top-heavy, both are probably overkill for documentation rendering (or, if not,
> what we'd need would be a browser plugin allowing to peruse that documentation
> in one's favourite browser).
> 
> To put my question into perspective: I'd be all for using a lightweight
> rendering backend rather than WebKit or WebEngine. QTB is just a bit too light
> but still it's what you get (in Assistant) when you build Qt from the aggregate
> tarball or install it via the official installers.

A while ago I played a bit around with [Qt]WebKit sources and tried to cut
it down to a bare bones Qt doc renderer. One certainly can get things smaller
quickly, Webkit source *is* quite modular after all, but at some point there
are question like "what about video? JS?", and while "No" might be an acceptable
answer from a user's point of view it's not trivial to amputate there without
impacting page history or some rarer-but-existing use cases.

Andre'