On 27.06.19, 10:47, "Development on behalf of Jaroslaw Kobus" <development-boun...@qt-project.org on behalf of jaroslaw.ko...@qt.io> wrote:
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. .... OK, if we can't use QTextBrowser, then what are our other options? 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. Here are the requirements, based on what other developer tools and platforms have: 1. The ability to copy code snippets directly from Qt's documentation (Creator or Web) and paste it into your code: https://docs.microsoft.com/en-us/cpp/linux/configure-a-linux-project?view=vs-2019 2. The ability to track what has changed in Qt's APIs from version to version with a dropdown box, where you can select the SDK version and then the documentation rendering dynamically adapts to show what's new, what was changed, and what was deprecated. This goes all the way down to every single type. Notice how the context changes when you select a different XCode SDK, in this case: https://developer.apple.com/documentation?changes=latest_major 3. The ability to teach a customer, incrementally, step-by-step, how to use a new Feature. Think of teaching a Designer how to use QML or Qt 3D Studio in a simple way: https://developer.apple.com/tutorials/swiftui/creating-and-combining-views Scroll down this page, slowly, and see how its dynamic content changes to teach high-level concepts in a beautiful way. Reference documentation is not the only type of documentation people read in an IDE. Quite the contrary. This feature would also be amazing for customers who need to port from QMake to CMake. 4. The ability to categorize different types of tips, Notes vs. Important hints: https://docs.microsoft.com/en-us/xamarin/android/platform/files/ 5. The ability to mark certain code snippets as not recommended, for example, comparing between best practices vs. less-performant code to give more hints to developers: Rust does this well: https://doc.rust-lang.org/book/ch16-01-threads.html#using-move-closures-with-threads This is the competition Qt is up against today and Qt cannot choose to apply concepts like that because of Qt Assistant and Qt Creator. 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. OK, so how would we patch QTextBrowser? How many more tickets should be filed? * https://bugreports.qt.io/browse/QTBUG-67439 -- says that style sheets are not being parsed correctly in Assistant. The customer looked for info on how the QTextBrowser used in Assistant parse's stylesheets but hasn't been able to find any information and they were hoping to modify their CSS to parse this correctly. So we don't even give our customers this information. * https://bugreports.qt.io/browse/QTBUG-33336 -- there's a comment here in the ticket that says 'Please bear in mind that QTextBrowser is not a HTML viewer and will never handle all possible dialects of HTML sufficiently.... Displaying 3rd party web content which is not under your control is something which requires a fullblown web engine.... This will never be supported in QTextBrowser, as it would mean something like duplicating WebKit (WebEngine) inside of QtGUI, which would of course defeat its purpose." 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@qt-project.org https://lists.qt-project.org/listinfo/development
