[Development] Assistant WebKit/WebEngine support

[Konrad Rosenbaum]

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 2456 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190625/70ab2525/attachment.key>