[Development] Assistant WebKit/WebEngine support

[Samuel Gaist]

> On 28 Jun 2019, at 07:59, Martin Smith <Martin.Smith at qt.io> wrote:
> 
>> That's what I'm trying to explain. I can't use what Creator gives me right now
>> as it doesn't match what is published on Qt's very own documentation site
>> (https://doc.qt.io).
> 
> Shouldn't Creator go directly to the documentation site to get what it needs?

Hi,

Please, no.

One of the strong point of Assistant or the Qt Creator help module is that you have the full Qt documentation at hand
whenever you need it with or without internet connection.

Personally, I’d rather avoid the always online mode. Not everybody has a good quality internet link nor unlimited data plan.
I know it’s "only documentation" and it’s going to be compressed, etc to lower bandwidth usage but still, the less
data you need to download the better.
You have people that have to work in restricted environments who might not even have internet access for that matter.
So even if the documentation is somehow cached after download, it’s still going to be an additional check to do and network
usage need that doesn’t exists currently.

Best regards

Samuel

> 
> ________________________________________
> From: Development <development-bounces at qt-project.org> on behalf of Palaraja, Kavindra <KPalaraja at luxoft.com>
> Sent: Friday, June 28, 2019 7:40 AM
> To: development at qt-project.org
> Subject: Re: [Development] Assistant WebKit/WebEngine support
> 
> On 27.06.19, 20:59, "Development on behalf of André Pönitz" <development-bounces at qt-project.org on behalf of apoenitz at t-online.de> wrote:
> 
> ....
>> People propose adding functionality to QTextBrowser instead. I do not
>> thing that’s a viable solution (we’ve tried that in the past and our
>> technical writers hit the next issue some weeks/months later). The
>> problem is not that one could not add support for one or two new
>> features to QTextBrowser, it is that we do not know what features we
>> will need in our docs in the future.
> 
>    The current feature set is kind of sufficient to get the job done.
>    Nobody claims that it is perfect or even close to that. Also, my "our"
>    technical writers (which surprisingly seem to be different from your
>    "our" technical writers) hinted that the missing table borders might
>    actually be a recent regression in QTextBrowser.
> 
> Andre, you are trying to reduce the problem down to "one table rendering bug" and otherwise saying "it gets the job done."
> 
> I have demonstrated in earlier e-mails that the problem is actually threefold:
> 
> 1. Our users are complaining that their own External Content is not rendered correctly since 16 March 2016: https://bugreports.qt.io/browse/QTCREATORBUG-15887
> 2. Our own official documentation, generated with the official qdoc, also does not render correctly.
> 3. The technology we are using to display the documentation is not futureproof. I have demonstrated this by giving multiple example of how our competition is using today's technology to convey difficult technical topics in a beautiful and intuitive way to attract and retain their users.
> 
> As you've read in another e-mail, we've officially lost Richard as a user. He's not going to use Creator's Help Integration anymore.
> 
>> And that we (as Kavindra pointed out) are wasting a lot of our
>> technical writers time trying to ensure the content is rendered in a
>> somewhat usable way in Creator.
> 
>    The time is wasted only if the result cannot be used, e.g. when one
>    doesn't take the target environment into account when doing the work.
> 
> That's what I'm trying to explain. I can't use what Creator gives me right now as it doesn't match what is published on Qt's very own documentation site (https://doc.qt.io).
> As a customer, you don't even realize you've fallen into this problem as it's not mentioned anywhere in the documentation for using the QtHelp Framework https://doc.qt.io/qt-5/qthelp-framework.html
> Notice that QTextBrowser only shows up once there, and nothing is mentioned about its limitations.
> 
> Kavindra.
> 
> 
> ________________________________
> 
> This e-mail and any attachment(s) are intended only for the recipient(s) named above and others who have been specifically authorized to receive them. They may contain confidential information. If you are not the intended recipient, please do not read this email or its attachment(s). Furthermore, you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and then delete this e-mail and any attachment(s) or copies thereof from your system. Thank you.
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development

-- 
Samuel Gaist
Research And Development Engineer
Idiap Research Institute, 
Centre du Parc, 
CP 592, 
CH-1920 Martigny
http://www.idiap.ch/