<div dir="ltr">> 
Feel free to correct/critique my assessment and to add more options if<br>
you see any. Otherwise: chose your poison.<div><div dir="ltr" class="m_3693125598370779358gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><br></div><div>There's also Zeal which is a nice Qt-based documentation browser which covers much more than the current .qch offering: <a href="https://zealdocs.org/" target="_blank">https://zealdocs.org/</a> & <a href="https://github.com/zealdocs/zeal">https://github.com/zealdocs/zeal</a></div><div><br></div><div>I see it used more and more.</div><div><br></div><div>Best,</div><div>Jean-Michaël</div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 25, 2019 at 11:54 PM Konrad Rosenbaum <<a href="mailto:konrad@silmor.de" target="_blank">konrad@silmor.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
On 6/25/19 9:59 PM, Tor Arne Vestbø wrote:<br>
> On 25 Jun 2019, at 21:30, Konrad Rosenbaum <<a href="mailto:konrad@silmor.de" target="_blank">konrad@silmor.de</a>> wrote:<br>
>> Pardon my lingo,<br>
> You should be able to communicate your points without that kind of lingo. Try better.<br>
><br>
>> It is documentation for developers for crying out loud! Its purpose is not to win any design prices, but to educate the developers.<br>
> Please stop putting up straw-men, it’s not helping this discussion at all.<br>
<br>
Okay, let's formulate this in a way that hopefully doesn't offend you<br>
and doesn't seem like a straw-man to you.<br>
<br>
<br>
Qt6 has a couple of options for documentation, none of them are ideal:<br>
<br>
<br>
Option 1: leave everything as is with a QTextBrowser based assistant and<br>
some tweaks in the qch files.<br>
Pros: no additional work required; all current features and use cases<br>
stay supported; good enough for a lot of developers<br>
Con: looks ugly enough to actually offend visually sensitive developers.<br>
<br>
<br>
Option 2: put some elbow grease into QTextBrowser and make it understand<br>
some more tags and more CSS.<br>
Pros: documentation becomes visually more pleasing; minimal dependencies<br>
by assistant - easy to build and easy to bundle with applications;<br>
embedding in Creator or KDevelop etc. stays easy to do<br>
Positive side effect: users will love it, since it becomes much easier<br>
and flexible to use QTextBrowser in their own applications<br>
Con: someone actually has to put in the work<br>
<br>
<br>
Option 3: bring back WebKit<br>
Pros: looks beautiful; uses up less memory than WebEngine<br>
Cons: someone has to put up lots of work to actually support WebKit;<br>
uses up lots more memory than QTextBrowser; adds a dependency to<br>
assistant (makes it less useful for redistribution); embedding in IDEs<br>
is slightly more complex and adds a dependency<br>
<br>
<br>
Option 4: convert to WebEngine<br>
Pros: looks great; currently supported browser engine, only little<br>
porting work<br>
Cons: horrible memory footprint; acute terminal featuritis; adds lots of<br>
dependencies (disqualifies it for most/many people redistributing it);<br>
does not work on all platforms supported by Qt (makes assistant less<br>
useful or even useless to those users); embedding in IDEs becomes much<br>
more difficult (dependencies and #ifdef's for unsupported platforms)<br>
<br>
<br>
Option 5: use WebView<br>
Pros: might look good<br>
Cons: either looks bad or adds whatever component WebView wants to use<br>
as a dependency; unpredictable results<br>
<br>
<br>
Option 6: use plain platform browser to show local files<br>
Pros: minimal footprint; assistant can be retired; guaranteed good rendering<br>
Cons: you never know which browser the user installs; abandon QCH<br>
format; implementing search becomes a horrible mess of JS and other<br>
files - requires extensive tool support to generate this - doubtful that<br>
it will always work; forget embedded viewers - this would require<br>
WebEngine or WebKit again; some users will hate the fact that assistant<br>
is missing or at least unsupported<br>
<br>
<br>
Option 7: platform browser plus server process to deliver help via local<br>
HTTP<br>
Pros: like Option 6, but search becomes easier to implement<br>
Cons: like Option 6, except search; someone needs to implement a simple<br>
HTTP server (not that hard, but requires some work) and a search engine<br>
(slightly harder, but solvable)<br>
<br>
<br>
My personal favorite would be Option 2 (better QTextBrowser), followed<br>
by Options 1 (status quo) and 3 (WebKit) in no particular order. But<br>
since I'm not willing to put in any serious work or pay for it - my vote<br>
does not count - I'm just a user. ;)<br>
<br>
Feel free to correct/critique my assessment and to add more options if<br>
you see any. Otherwise: chose your poison.<br>
<br>
<br>
<br>
    Konrad<br>
<br>
<br>
_______________________________________________<br>
Development mailing list<br>
<a href="mailto:Development@qt-project.org" target="_blank">Development@qt-project.org</a><br>
<a href="https://lists.qt-project.org/listinfo/development" rel="noreferrer" target="_blank">https://lists.qt-project.org/listinfo/development</a><br>
</blockquote></div>