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

[Konstantin Tokarev]

> 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.

Perhaps we could add "minimal" configuration for QtWebKit in Coin, with disabled
QML API, multimedia features, and "extra" stuff like WebGL and geolocation.
This is often requested by users and one of the top reasons why they build
QtWebKit on their own when binaries are available [1].

Of course it won't be nearly lean and mean as what you described above, however
it requires virtually no extra maintenance and is unlikely to break on user content.
And it will reduce binary size substantially and cut off dependencies.

[1] Other popular reason is that people want to use 5.212 branch with Qt 5.6,
but Coin currently does not support building same branch against several Qt versions 

> 
> Andre'
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
-- 
Regards,
Konstantin