Re: [Development] Assistant WebKit/WebEngine support
On 27/06/2019 21:02, Thiago Macieira wrote: On Thursday, 27 June 2019 01:07:45 PDT Konrad Rosenbaum wrote: Please also keep in mind that a fair number of developers use the same tool-chain (qdoc, assistant, QtHelp) to generate their own documentation - this means that assistant gets redistributed. Ah, but this is an issue: assistant. See the thread about co-installability of Qt 5 and Qt 6: is assistant as a standalone application still required? You're saying it is. Indeed it is required. Please don't take Assistant away from me entirely. https://lists.qt-project.org/pipermail/development/2019-June/036704.html Bastiaan. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
A very good post, thank you Jarek. Ideally, Qt would have a dedicated HTML renderer that works on all platforms, without unnecessary overhead and security issues. Possibly as a new widget (QHtmlBrowser) to keep QTextBrowser strictly rich text, possibly removing features from QTextBrowser to make it truly minimal. The Qt Company, inventors of QML, should be in a good position to accomplish such a stand alone HTML browser. However, it seems that most web browsers that implemented their own browser tech have ditched those in favour of a third party framework (see Opera, Edge, e.g.) -- how much of the reason for that is due to rendering or networking I don't know. Either way, accomplishing decent standard compliance will require a major investment. A business decision should be made whether that investment isn't better spent on teaming up with a third party to make its framework modular, so that it is capable of working optimally for offline content. If that is implemented well, this could potentially mean that on the platforms that use this framework for their native browser, QHtmlBrowser could simply forward to the system shared library for HTML rendering (without networking). Gecko, WebKit and Chromium seem to be the major browser back ends. Which of those is best to team up with? Both WebKit and Chromium are derived from KHTML, so maybe KHTML is a good starting point due to its relation with Qt. Or, if WebKit and Chromium aren't easily modularised, maybe that is because of how KHTML is put together, and a fresh look at Gecko is beneficial? I agree with Jarek that Qt should plan long term and implement the best solution, not the easiest or quickest. It has been bad for four years already, a year or two more is not a big deal. People that require Assistant with full HTML/CSS capability can get that easily today[1], and can wait. Bastiaan. [1] https://github.com/veelo/qttools ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On 27/06/2019 06:57, Richard Weickelt wrote: Qt used to make a point on having superior documentation to most other frameworks, and it was (and still is) one of the reasons for its success. Whatever we can do to help make the documentation better is something I think we should do. [...] I stopped using the integrated help and QtAssisant at some point and now I am exclusively using the online documentation in my regular browser. I can't give an exact reason, but I can see a correlation of multiple things: [...] 5) There was the point where Qt's online docs started to look better. Cripser fonts, more whitespace, better code highlighting. I guess no matter how hard you try and how much effort you put into it, I'll probably never use QtCreator's integrated help again. You just listed one of the deficiencies of QTextBrowser as a reason to not use Qt for browsing its documentation. That's like saying it's bad, so there is no point in making it good. Bastiaan. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On 25/06/2019 18:16, Thiago Macieira wrote: On Tuesday, 25 June 2019 09:05:21 PDT Konstantin Tokarev wrote: It hasn't been updated in years. Don't use it, since it's clearly not getting security updates. New version is currently in development, and should be ready in time frame of Qt 5.14 (at least functionality required for displaying help) 5.212 branch should be fine for use with local help files, e.g. you can take fresh\ from http://download.qt.io/snapshots/ci/qtwebkit/5.212/1560153112/ Konstantin, at this point, what's speaking againt qtwebkit is its track record of release. Until it starts making regular releases again, I can't recommend it. And Qt Creator (or any other application) shouldn't begin using it again until those regular releases resume. Are you worried about the lack of security patches? I can see how that matters for an ordinary browser implemented with Qt, but for Assistant and Creator that exclusively display locally installed generated compressed help files, security concerns are a lot lower. Bastiaan. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On 26/06/2019 00:15, Jean-Michaël Celerier wrote: There's also Zeal which is a nice Qt-based documentation browser which covers much more than the current .qch offering: https://zealdocs.org/ & https://github.com/zealdocs/zeal I see it used more and more. Best, Jean-Michaël That's QWebView based (WebKit) pre Qt 5.6. Back then Assistant was great as well. Bastiaan. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On 25/06/2019 21:30, Konrad Rosenbaum wrote: It is documentation for developers for crying out loud! No it is not. Assistant is distributed as a help viewer, to be distributed along with applications for use by the customers of your customers. As soon as QTextBrowser in its current sorry state of rendering HTML became the sole supported browser, it completely FAILED that purpose. Not just "a little bit more Spartan but we can live with it", no, it leaves out *critical* information! It is completely undistributable in our case. Firstly the fonts are a complete mess, with different elements having unrelated sizes, weights and types. If you zoom, only the headings zoom! We use styled to accomplish frames around labels to refer to elements in screen shots[1] that vanish in QTextBrowser. We use CSS styled tables to render hyperlinked menus that occur in the user interface, and the borders should be there because they are there in the UI; they are not in QTextBrowser. We have hundreds of these menus in multiple translations, and screen shots are just not going to work in a 400-page manual. Try keeping those up to date. And what about those hyperlinks? Don't you dare suggest those HTML 1.0 tables. We use CSS styles description links to highlight call-outs[2]. They don't work in QTextBrowser. Deciding that it was okay to drop Qt WebKit in Qt Assistant because with some tweaking of your content the Qt documentation for Qt developers could be made kind of acceptable to some people was a complete let down and Qt's biggest mistake so far. Pardon my lingo. Bastiaan. [1] https://www.sarc.nl/images/manuals/pias/htmlEN/loading_module_gui.html#loading_gui_layout [2] https://www.sarc.nl/images/manuals/pias/htmlEN/fwy_export.html ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On 21/06/2019 11:08, Bastiaan Veelo wrote: [...] 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. I went ahead and did this. https://github.com/veelo/qttools is a fork of qttools for the sole purpose of compiling Qt Assistant against a stock binary distribution of Qt as an independent application. It compiles quickly and conveniently using Qt Creator. The 5.13_assistant_webengine branch contains the WebEngine support by Allan Sandfeld Jensen and several additional fixes of my own. At least I have a working solution without the need to wait until the next morning for compilation of Qt and WebEngine to complete, with reasonable odds of being able to keep in sync with upstream and future releases. Bastiaan. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On 21/05/2019 14:50, Konstantin Tokarev wrote: 21.05.2019, 15:47, "Bastiaan Veelo" : On 20/05/2019 19:02, Konstantin Tokarev wrote: [...] Current version of QtWebKit from 5.212 works on Windows, there are binaries at http://download.qt.io/snapshots/ci/qtwebkit/5.212/latest/qtwebkit/ Extracted into qtbase and Assistant builds like a charm! However running it gives "The procedure entry point ?staticMetaObject@QSslSocket@@2UQMetaObject@@B could not be located in the dynamic link library D:\Qt\gerrit\qt5\qtbase\bin\Qt5WeKit.dll". I have checked out the Qt dev branch from May 11, which I can imagine could cause problems. Do you happen to know which Qt version those QtWebKit binaries are known to work with? 5.10 I decided not to compile Qt myself any more, because I can't wait until the next day for it to finish each time. Therefore I have forked qttools and am compiling Assistant separately using a stock binary Qt distribution. For some reason though, 5.10 is completely absent from the installer. I'll have to let the WebKit approach rest for the time being. Bastiaan. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On 24/06/2019 22:44, Lars Knoll wrote: Another +1 from me. Let’s stop fighting this. We need something that can properly display any HTML content (and maybe PDF and things as well) that we throw at it. Thank you. Bastiaan. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On 21/06/2019 15:47, Konstantin Tokarev wrote: 21.06.2019, 16:40, "Bastiaan Veelo" : On 21/06/2019 14:57, Volker Hilsheimer wrote: 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? Volker [1] https://lists.qt-project.org/pipermail/development/2019-May/036028.html In our application, we already provide our manual in three different formats, generated from the same source (by doxygen): qhc/Assistant, PDF and HTML served from our company website. The great advantage of qhc and Assistant is that the content in Assistant can be easily and efficiently synchronised by the click of some specific "Help" button in the UI to bring up content specific to the context of that button, without creating new tabs in your web browser. The most important feature of Assistant, though, is its index and search functionality. Will qthttpserver be able to do that, scrolling to the right position and highlighting the indexed word? This is doable by using URLs with anchors and using clever JS-based routing inside HTML help page But then Doxygen must be extended to generate that cleverness, right? ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On 21/06/2019 14:57, Volker Hilsheimer wrote: 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? Volker [1] https://lists.qt-project.org/pipermail/development/2019-May/036028.html In our application, we already provide our manual in three different formats, generated from the same source (by doxygen): qhc/Assistant, PDF and HTML served from our company website. The great advantage of qhc and Assistant is that the content in Assistant can be easily and efficiently synchronised by the click of some specific "Help" button in the UI to bring up content specific to the context of that button, without creating new tabs in your web browser. The most important feature of Assistant, though, is its index and search functionality. Will qthttpserver be able to do that, scrolling to the right position and highlighting the indexed word? Bastiaan. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On 21/05/2019 12:24, Kai Köhne wrote: -Original Message- From: Development 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 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CSS styling, XML, HTML etc. (was Re: Assistant WebKit/WebEngine support)
[skipping many interesting points, sorry] On 21/05/2019 16:06, Shawn Rutledge wrote: Anyway I think Assistant is one of those cases where I would prefer to keep using QTextBrowser and fix it up a bit more to suit, rather than switching to a real browser engine. Light weight is a real advantage. Creator already takes up enough memory as it is, with its code model especially. And documentation doesn’t need most of the fancy HTML features either. A better QTextBrowser would be very much welcomed, but there may still be cases where Assistant needs more features. The question of what HTML features are necessary depends on the application. In user applications, Assistant is not used to display code documentation (which is quite simple) but help files, which may require a much greater feature set. If it were possible, it could even be desirable to include small video clips as instructions for performing certain tasks. So there may still be applications where a full browser stack would be desirable. One could argue that one should spawn a real browser instead, but the index and search facilities in Assistant are invaluable. -- Bastiaan. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On 20/05/2019 19:02, Konstantin Tokarev wrote: 20.05.2019, 19:58, "Bastiaan Veelo" : On 20/05/2019 17:56, Konstantin Tokarev wrote: 20.05.2019, 18:27, "Bastiaan Veelo" : On 20/05/2019 16:51, Konstantin Tokarev wrote: Note that it should be possible to rebuild QtTools with QtWebKit support, for example this configuration is supported in Gentoo out of the box. [...] But not on Windows, am I right? Why not? Current version of QtWebKit from 5.212 works on Windows, there are binaries at http://download.qt.io/snapshots/ci/qtwebkit/5.212/latest/qtwebkit/ Extracted into qtbase and Assistant builds like a charm! However running it gives "The procedure entry point ?staticMetaObject@QSslSocket@@2UQMetaObject@@B could not be located in the dynamic link library D:\Qt\gerrit\qt5\qtbase\bin\Qt5WeKit.dll". I have checked out the Qt dev branch from May 11, which I can imagine could cause problems. Do you happen to know which Qt version those QtWebKit binaries are known to work with? Thanks, Bastiaan. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On 21/05/2019 12:24, Kai Köhne wrote: -Original Message- From: Development 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. Thanks for letting me know. [...] I have been looking into the plugin idea, and although it is not straight forward I think it is doable. Some larger refactoring is needed to achieve a clean border between Assistant and the viewer plugin interface. My goal is to eliminate calls from the viewer plugin back into the Assistant application, which would otherwise require some classes to be in a common shared library. I can implement the QTextBrowser based viewer in a plugin that is statically linked, so that Assistant will work out of the box whether it is being deployed with or without WebEngine. Plugins can be selected based on priority. That sounds like a good approach to me. Another abstraction you might consider is using Qt WebView as universal backend: https://doc.qt.io/qt-5/qwebengineview.html Qt WebView is an abstraction for showing web content, using different backends on different platforms. It is currently geared towards the mobile platforms, using Qt WebEngine as default backend on the desktop. Anyhow, it has already an (experimental) backend on macOS using Safari, and my hope is that we can make it also work with the new Chromium based Edge browser on Windows, see https://bugreports.qt.io/browse/QTBUG-75747 . Anyhow, I'm not sure the QtWebView API is actually capable enough to cater for Qt Assistant. One obvious challenge is that you've to pass a url to the engine that it can actually resolve. This probably means either extracting the html in the .qch files to a local directory, or even running a minimal local web server. There might be even more functionality missing ... But Qt WebView has already a plugin infrastructure, so you can at least take inspiration from there 😊 Although I haven't looked at QtWebView's API yet, it seems that indeed the best solution would be to add support for the qthelp scheme to QtWebView, possibly in a plugin to it? Konstantin mentioned that this has been discussed before. I think the abstraction could be taken from Qt Creator, https://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/plugins/help/webenginehelpviewer.cpp#n123, class HelpUrlSchemeHandler. I just had a glance at Qt Creator like Konstantin suggested. From what I can see, the help viewer itself is implemented as a Creator plugin, but the backend is determined at compile time much like Assistant is doing it currently. There is a lot of code duplication between Assistant and Creator, so it would be good to unify that code somewhere. Assistant's challenge compared to Creator is the build order. Creator is built independently from Qt so it has no problems using QtWebEngine. Within a clean Qt clone however, Assistant is built before QtWebEngine, which is the main reason why https://codereview.qt-project.org/c/qt/qttools/+/111559 can't be pulled. So that is the main motivation for a plugin system. I am assuming that the same issue would exist if Assistant were to use QtWebView, as I assume the latter depends on QtWebEngine as well? In that case there would still be a build order problem. Can you confirm that? I don't know enough about Qt's build system to know what is necessary to defer the build of Qt Assistant until after QtWebEngine/QtWebView has finished building. If that's necessary for using QtWebView then it would be good to focus on that first. When that's done then the existing WebEngine support PR can simply be merged into Assistant, which would close the long standing issue https://bugreports.qt.io/browse/QTBUG-55866. Then refactoring backend details from Creator and Assistant into WebView could be done at leisure. [...] Also, would you mind creating a JIRA item for this ? This way it's easier to track... There's this: https://bugreports.qt.io/browse/QTBUG-55866, that will do, right? Thanks, Bastiaan. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On 20/05/2019 17:56, Konstantin Tokarev wrote: 20.05.2019, 18:27, "Bastiaan Veelo" : On 20/05/2019 16:51, Konstantin Tokarev wrote: Note that it should be possible to rebuild QtTools with QtWebKit support, for example this configuration is supported in Gentoo out of the box. Interesting, I would not have guessed. The way I currently do the refactoring is breaking that possibility, though. It could be restored (I guess) by moving that code into a WebKit based plugin. But I'm not planning on installing Gentoo to implement and test that You actually don't need to install Gentoo. QtWebKit support is enabled automatically if you compile Assistant after installation of QtWebKit. But not on Windows, am I right? If continued WebKit support is desired, and the plugin idea is welcomed, would you @Konstantin be able to help finish the WebKit plugin? Sure. Appreciated. However, it would better to avoid duplicating work with Qt Creator, which also implements HelpViewer interface with different backends. Some time ago there was a discussion that such shared interface & plugin system should belong to Qt Web View module. But that would probably require more work to be done. That would be nice. Do you have a pointer to that discussion? I only found https://lists.qt-project.org/pipermail/qt-creator/2017-September/006740.html. As you might have guessed, I am not a regular here. Or do you think that removing WebKit support from Assistant completely would be better, if WebEngine shows to be working well? As for me, I'm totally fine with QTextBrowser I wish that were true for me. We need colours in table cell borders and SVG images (and better CSS support would be real nice). This might help, but is stalled: https://codereview.qt-project.org/c/qt/qtbase/+/177256 -- Bastiaan. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On 20/05/2019 16:51, Konstantin Tokarev wrote: 20.05.2019, 16:02, "Bastiaan Veelo" : [...] Qt Assistant officially only renders content with QTextBrowser currently, which is too limited for many of us[1]. There are still traces of greater WebKit times, but that code remains unused after WebKit was dropped from Qt. Note that it should be possible to rebuild QtTools with QtWebKit support, for example this configuration is supported in Gentoo out of the box. Interesting, I would not have guessed. The way I currently do the refactoring is breaking that possibility, though. It could be restored (I guess) by moving that code into a WebKit based plugin. But I'm not planning on installing Gentoo to implement and test that, and without WebKit being part of mainline Qt I'm not sure such a plugin should be either, especially when things are working with WebEngine. If continued WebKit support is desired, and the plugin idea is welcomed, would you @Konstantin be able to help finish the WebKit plugin? Or do you think that removing WebKit support from Assistant completely would be better, if WebEngine shows to be working well? -- Bastiaan. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[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. Qt Assistant officially only renders content with QTextBrowser currently, which is too limited for many of us[1]. There are still traces of greater WebKit times, but that code remains unused after WebKit was dropped from Qt. There have been talks about WebKit making a return[2], but it has been quiet on that front for some time. There has been an initiative for using WebEngine as an alternative, which mostly works[3]. However, that patch assumes the WebEngine build to have completed when Assistant is being built, which is not the case in a clean checkout. To resolve this dependency order problem, it has been suggested in its review to redo WebEngine support as a plugin to Assistant. I have been looking into the plugin idea, and although it is not straight forward I think it is doable. Some larger refactoring is needed to achieve a clean border between Assistant and the viewer plugin interface. My goal is to eliminate calls from the viewer plugin back into the Assistant application, which would otherwise require some classes to be in a common shared library. I can implement the QTextBrowser based viewer in a plugin that is statically linked, so that Assistant will work out of the box whether it is being deployed with or without WebEngine. Plugins can be selected based on priority. Having the viewer back end be separated from the application with a plugin interface may be an advantage regardless, whether WebKit comes back or WebEngine is being removed from the Qt distribution in the future. At least users will have a possibility to replace the default viewer with whatever alternative is available. Does this sound like a good idea? Thanks, Bastiaan Veelo [1] https://bugreports.qt.io/browse/QTBUG-55866 [2] https://forum.qt.io/topic/102816/webkit-status-2019 [3] https://codereview.qt-project.org/#/c/111559/ ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
