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

[René J.V. Bertin]

On Saturday November 11 2017 02:57:01 Konstantin Tokarev wrote:

>> Back to the topic of this discussion. We've recently switched to Qt WebKit 5.212

What Qt version does that correspond to? WebKit is just being maintained for compatibility with its Qt dependencies, no?

>> , and sadly it didn't make all our problems go away due to a number of regressions. And even if Qt WebKit worked perfectly, a full scale browser engine still feels like an overkill for a simple task of displaying documentation.

I couldn't help but notice that Zeal also dropped WebEngine support...

>I think unless you have a full control over the content (or content authors intentionally test it with QTB), you have to support all of HTML and CSS modern engines implement, and maybe even some JS.

I think you do have to draw a line here. Documentation writers might go overboard with fancy bells and whistles (possibly/probably ignoring common sensical guidelines on how documentation should be formatted to make users more productive). A dedicated documentation browser can (and probably should IMHO) focus on the accepted productivity principles, empowering users to focus (immediately) on the essentials (read: what they were looking for) and without distracting them from the task at hand. All while remaining lightweight and not more resource hungry than strictly necessary.
In my book that means it shouldn't try to be a full-fledged web browser (even if just implicitly by using a "full-browser-in-a-widget" library like WebEngine). An actual web browser is always going to do a better job at rendering complex documents - it's designed for that job. A documentation viewer should focus on whatever sets that kind of application apart - and I don't think it's bad to focus on the specific case of API/SDK documentation in the case of Qt's Assistant.

Somebody mentioned video. I don't think that's a crucial feature in an application that's mostly intended for developers who don't know all APIs by heart.

If that means that some documentation doesn't display correctly ... providing an option to hand off the document to the user's web browser shouldn't be hard, right? Aside from the fact that there could be a choice of rendering backends (even at runtime as someone reading this recently proposed ;) )

>> QTextBrowser while quite capable often struggles with displaying anything but very basic pre-HTML5 content, plus it doesn't support HiDPI screens. Improving QTB is an idea I occasionally entertain, but that would require a significant time investment.

HiDPI support is probably something that should be implemented for QTB independent of this discussion. We've noticed that it also fails to work well with expandable sections in doxygen-generated documentation.

>> Another alternative I am currently considering is falling back to MSHTML on Windows. There was a similar effort for Qt Assistant in the past [2], but didn't make it. For a documentation viewer MSHTML should provide everything required.

On Mac it might be possible to tap into the system's WebKit framework. Both approaches probably mean writing considerable amounts of glue; isn't there an existing 3rd party library that ought to be better suited than QTB without attaining WebKit or WebEngine complexity and that already has all required Qt bindings?
KHtml, maybe? I know it's obsolete for actual web browsing but security risks should be much less or more containable in a documentation viewer...

Cheers,
René