> On 21 Jun 2019, at 15:05, Simon Hausmann <simon.hausm...@qt.io> wrote: > > > Am 21.06.19 um 14:57 schrieb Volker Hilsheimer: >>> On 21 Jun 2019, at 11:08, Bastiaan Veelo <basti...@veelo.net >>> <mailto:basti...@veelo.net>> wrote: >>> >>> >>> On 21/05/2019 12:24, Kai Köhne wrote: >>>>> -----Original Message----- >>>>> From: Development <development-boun...@qt-project.org >>>>> <mailto:development-boun...@qt-project.org>> On Behalf Of >>>>> Subject: [Development] Assistant WebKit/WebEngine support >>>>> >>>>> Hi, >>>>> >>>>> I am prepared to do some work on Qt Assistant, and I'd like to know >>>>> how that >>>>> will be received. >>>> Cool, great you want to tackle this 😊 >>>> >>>> I'm sure Jarek (the official maintainer) will also share his >>>> thoughts, but he's out >>>> of office this week. >>> >>> Jarek, could you please review this thread[1] and share your thoughts? >>> >>> One aspect to keep in mind is that although sharing code with >>> QtCreator and/or using Qt WebView may sound like a better end >>> solution than writing a WebEngine plugin to Assistant, it probably >>> won't address the primary reason for writing the plugin, which is >>> build order. Assistant is currently built before Qt WebEngine, which >>> is why the existing patch[2] does not work in a clean checkout. If we >>> were to switch to Qt WebView, I assume compilation of Assistant would >>> have to be postponed just the same. The best solution would therefore >>> be, in my opinion, to change the order of compilation, apply the >>> existing patch, and consider refactorings and unifications thereafter. >>> >>> Bastiaan. >>> >>> [1] >>> https://lists.qt-project.org/pipermail/development/2019-May/035920.html >>> [2] https://codereview.qt-project.org/c/qt/qttools/+/111559 >> >> >> I’m not Jarek, but I recall that Eddy made a suggestion [1] which I >> think has been prematurely dismissed or at least not been discussed >> sufficiently, which is: >> >> * move the Qt Assistant functionality for searching and qch support >> into a locally executed HTTP server >> * use any proper webbrowser to display the help that this web service >> serves >> >> >> What would be arguments against such a solution? >> > > I think it's a good alternative option. In practice, how would this look > like? > > > Would we provide a menu in the start menu for "Qt documentation" that > would launch the web server and then the user preferred web browser with > that url? How is the server terminated?
Perhaps. But then, how many of us run dockerd on our local workstation? Or libvrtd? Why not a Qt service that serves the Qt documentation? Why bother with shutting it down? > Either way, this requires developing either a new frontend application > first or a back-end that can do the index searches, etc. Indeed. > To me it seems easier to solve this first by making the Qt Assistant use > WebEngine and when we later have a better doc "frontend" (as web app) > switch to that and potentially an external browser. Personally I think the “external browser”, as in “the browser that I read all other development documentation in”, should be a first choice for displaying Qt documentation. Volker _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
