>> But improving Assistant need not imply changing QtWidgets. There are two > >> solutions for this: > >> > >> 1) make qttools depend on qtwebengine > >> 2) make Assistant load a plugin that is provided by qtwebengine (and >> qtwebkit) > > 3) Make assistant use the system browser. > > I've been wondering since a while how hard this would be - most platforms > support embedding a browser in some way (see also Qt WebView). The obvious > obstacle is that Qt Help / Qt Assistant right now serves the .html in memory, > out of the .qch file. But we > might as well just extract the .html as files, and work from there...
Or use built-in HTTP server to avoid disk operations > > Kai > > From: Interest <[email protected]> on behalf > of Thiago Macieira <[email protected]> > > Sent: Friday, November 10, 2017 10:10:26 PM > > To: [email protected] > > Subject: Re: [Interest] [Development] Short/medium term evolution of the > Assistant? > > On Friday, 10 November 2017 11:41:56 PST André Pönitz 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. > > But improving Assistant need not imply changing QtWidgets. There are two > > solutions for this: > > 1) make qttools depend on qtwebengine > > 2) make Assistant load a plugin that is provided by qtwebengine (and qtwebkit) > > -- > > Thiago Macieira - thiago.macieira (AT) intel.com > > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > > Interest mailing list > > [email protected] > > http://lists.qt-project.org/mailman/listinfo/interest -- Regards, Konstantin _______________________________________________ Interest mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/interest
