[Development] Assistant WebKit/WebEngine support

[Jean-Michaël Celerier]

> Feel free to correct/critique my assessment and to add more options if
you see any. Otherwise: chose your poison.

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


On Tue, Jun 25, 2019 at 11:54 PM Konrad Rosenbaum <konrad at silmor.de> wrote:

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