[Development] Assistant WebKit/WebEngine support

[Jaroslaw Kobus]

QTextBrowser promises to render rich text - isn’t it what we want for showing help? If QTextBrowser isn’t able to render properly the static help files - what is the other typical usage of it? Why we claim that QTextBrowser is able to do things, which in fact it can't? This doesn't show a fair message to the user, if we - for our purposes - don't use tools which we should.

In webkit times I was able to open my bank online page from Assistant, but I wasn’t brave enough to log into my account. Do we really want help viewer to be full functional web browser? Big companies work hard for a very long time to design GUIs, menus, interactions, and we give the people barely the web window? I remember how I was confused when I could open my preferred online newspaper in Assistant in that time - it looked super unprofessional, without proper, typical GUI for web browsers around. Do we still want to pass the same impression to our customers?

IMO, we should make a clear requirements on what we want and what we don’t want for help viewer. There is no need for networking, means we even shouldn’t try to compile it against network module. Turning the networking functionality at runtime is not enough. We should make a clear separation, on what the viewer should support (like html, css), what it may potentially support in the future (we ensure we don’t close the door, e.g. playing offline videos), and what it shouldn’t support, never (networking, javascript (???), much more...). We should define it first and than choose the right solution. Not like: let’s choose webengine, it may do everything. Currently it looks like the webengine supports everything and it’s way too much.

In addition, I really don’t like the super fast decisions here. It’s easy to say: let’s use webengine, and after we release we will see if more or less people complain. Many things may be predicted now. It is a bit like: Would you use webengine to implement Qt’s "Hello World" example? One can say: why not, web engine may do much more! Is it a way we want to show our users on how to use Qt? We could even exchange the implementation of QLabel and use webengine for it... Less maintenance, smaller codebase, etc... Sound cosmic? Yeah, webengine in Assistant too...

Regarding Kavindra’s message, about not fixing QTextBrowser for years: yes, we were probably not having resources to do it so far. So, does that mean we should choose the bad further ways as a consequence? Isn’t it now the right time to address such long lasting issues? Would it be more interesting for users, that in Qt 6 the QTextBrowser is redesigned and can do much more than his old brother from Qt 5, instead of e.g. wondering for couple of years whether QList should be replaced / renamed / whatever by / to / ... QVector? I bet we would gain much more by enhancing QTextBrowser.

Does anyone still cares about what is the right way to do the stuff versus what is the fastest and easiest way to make a patch just to make some crying customers silent for a minute? Are we still pragmatic? I understand we aim with the solution for Qt 6 in any case. I imagine that making webengine pluggable / customizable / configurable (so that we even don't compile the stuff we don't want) won’t be possible in this timeframe - so, would we have enough time / resources to address much more easier changes in QTextBrowser, which would be really interesting for broad customer audience? Or we choose the easiest, crappy way (sorry for that, it’s just a quotation from this thread) and we just advertise it well enough? I bet smart developers (read: the users, which decide on whether to use or not to use the certain functionality of Qt in their projects) easily differentiate between a good change and a good ad.

Regards

Jarek

PS. Kavindra, yes, the goal of this thread is to address your issues. But please, let’s consider all the technical possibilities, before the decision on which way to choose is made. And please don’t stop considering changes in QTextBrowers, just because noone fixed it so far (for many years). It would be really handy if we have a bugreport with exact description of which html tags / attributes / css are broken in QTextBrowser. It would give an overview of how much needs to be done there. The evidence like: we tried before and failed, doesn't tell too much.