Re: [Development] Assistant WebKit/WebEngine support
Qt Creator 4.11 comes with an optional [[https://github.com/litehtml/litehtml][litehtml]] based help rendering backend. To change the used backend, go to Options > Help > General, and choose "litehtml" as the "Viewer backend". All new help viewers will use the changed backend, so e.g. after Qt Creator restart, after "Open Link as New Page", or after choosing "Reload" from the "split+" tool button menu on the right in the tool bar above the viewer. In our binary packages the available backends are "QTextBrowser" and "litehtml", and on macOS additionally "WebKit", which uses the native WebView component. The code for the litehtml backend is currently part of the Qt Creator repository. https://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/plugins/help/qlitehtml This adds a QPainter based backend for litehtml (not quite complete, but implementing the most important things that are also used in Qt documentation), and a simple QWidget that integrates that, with a simple API for setting the URL (as a base for links), the HTML content, zoom factor, default font, getting the HTML title, finding text and getting the selected content, and callbacks/signals for loading resources and reacting to clicks. This part is completely independent from Qt Creator and could be used elsewhere. Additionally there is a viewer backend implementation for Qt Creator that uses this widget. Br, Eike -- Eike Ziller Principal Software Engineer The Qt Company GmbH Erich-Thilo-Straße 10 D-12489 Berlin eike.zil...@qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On 25/06/2019 17.53, Konrad Rosenbaum wrote: > 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 Incidentally, does this help rich text rendering *everywhere*? Such as in tool tips, for example? -- Matthew ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
Catching up with mail discussions that have happened while I've been away, so sorry if I've missed some relevant part that covers this already ... On 25. Jun 2019, at 23:53, Konrad Rosenbaum wrote: >> 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) In fact, someone *has* done so, see QTBUG-60105 and the qthttpserver module, which aims to provide embeddable HTTP serving as a service from within arbitrary Qt apps. https://bugreports.qt.io/browse/QTBUG-60105 It's a work in progress and I won't promise it's yet ready to fill all your needs here; but, equally, it's in development and those needs would probably serve as an excellent test-case to help guide the design of what we do end up implementing. >> and a search engine (slightly harder, but solvable) Eike Ziller (26 June 2019 10:09) replied: > Also I see usability issues (for 6+7), since we probably cannot > control where the documentation opens when we request the browser to > do so. Opening a new tab/window any time the user presses F1 in Qt > Creator would be pretty bad. One solution to that would be for the client (Qt Creator) to open an URL to a container-page that then opens a web-socket [*] back to the client, which the client subsequently uses to load pages into the container. The client would open the container page once, the first time it wants to display something in the browser, and subsequently use the web socket to say which pages it wants to open for browsing. [*] Qt already includes web socket support; and, IIRC, qthttpserver knows how to serve it. Eddy, still recovering from a post-holiday cold. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On Montag, 24. Juni 2019 11:32:15 CEST Konstantin Tokarev wrote: > > Well, what I’d really like would be a lightweight RichText / HTML+CSS > > viewer without all the baggage of a complete internet browser. QTextBrowser > > does too little, QtWebEngine much too much. > > So, QtWebKit should be the right thing then? is it maintained and an integral part of a Qt delivery ? It makes little sense to add two web rendering engines into Qt (I would have loved to stay with QtWebKit, but impossible without having it maintained) -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\- against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On 27/06/2019 21:02, Thiago Macieira wrote: On Thursday, 27 June 2019 01:07:45 PDT Konrad Rosenbaum wrote: Please also keep in mind that a fair number of developers use the same tool-chain (qdoc, assistant, QtHelp) to generate their own documentation - this means that assistant gets redistributed. Ah, but this is an issue: assistant. See the thread about co-installability of Qt 5 and Qt 6: is assistant as a standalone application still required? You're saying it is. It is a documented feature that you "can use /Qt Assistant/ as the help viewer in your applications" (https://doc.qt.io/qt-5/qtassistant-index.html). There are commercial applications and open source applications relying on this for *user documenation*. The use of Qt Help tools outside Qt became fairly evident not so long ago when in Qt 5.12.0 a) qcollectiongenerator was (temporarily) removed in Qt 5.12.0, and b) Qt Assistant (temporarily) lost it is ability to show documentation from read-only locations (QTBUG-72174). For applications other than Qt Creator, increasing the size of Qt Assistant binaries might have a more significant effect. In the MinGW x64 build of my application, Qt Assistant (QTextBrowser), Qt5Help, Qt5Sql and the sqlite plugin account for app. 2.1 MB out of 54 MB binary files. Since the app is working with geospatial raster and vector data, also RAM is an issue for some users. I would certainly appreciate improved HTML/CSS support in QTextBrowser (or a replacement). But I do not want to pull in the equivalent of a web browser with networking and javascript just for the purpose of displaying and printing static offline docs from the file system. Let alone the possibility to build for MinGW. Kai. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
From: Development on behalf of Palaraja, Kavindra Sent: Friday, June 28, 2019 10:56 AM To: Qt development mailing list Subject: Re: [Development] Assistant WebKit/WebEngine support On 28.06.19, 10:24, "Eike Ziller" wrote: > On 27. Jun 2019, at 15:46, Palaraja, Kavindra wrote: > > ...because both you and Andre aren't willing to pay the price... No Kavindra, please count me in too. And my 13 years old son too, so that we are four now. He just told me a story, that he recently saw a video, that some simple calculator app required calling privileges during installation on a mobile phone. There is a good chance, that soon similar videos will appear regarding the installation of offline help for Qt, requesting networking privileges. Best regards Jarek ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
> On Jun 28, 2019, at 14:46, Palaraja, Kavindra wrote: > > On 28.06.19, 12:22, "Eike Ziller" wrote: > > > >> From your response, I'm only gathering two options: > >There are other options. >https://lists.qt-project.org/pipermail/development/2019-June/036712.html >summarizes many of them. >Additionally “strip down QtWebEngine or QtWebKit and support that”. >Or, separating "plain and simple API documentation" to be displayed > directly an Qt Creator/Assistant from “fancy tutorials” to be displayed by a > browser of the user’s choice. > > Just curious, how would you define "plain and simple API documentation”? A defined subset of static HTML+CSS. What subset of HTML+CSS exactly, is up for discussion of course. And yes, that option probably requires either fixing some things in QTextBrowser, or providing a different means of rendering non-dynamic HTML+CSS, depending on the outcome of that discussion. _None_ of the options come for free. > Developer documentation is split up into four categories: > > * API Reference -- the inline source code comments > * Conceptual documentation -- The qdoc files that we use to explain how to > use large modules > * Code samples -- The snippets and the Examples > * Strings -- error messages and Creator's strings > > Right now, with qdoc, all we have is "plain and simple API documentation", > the first three categories. Technically that is not quite true, since qdoc doesn’t restrict what kind of CSS + templates you use, which can also contain any JavaScript and any CSS. > None of this is fancy yet Creator/Assistant can't display it correctly. > >> 1. Live with it and hope that somehow this will solve itself in the future >> -- there is no evidence from the past years that this is going to happen. >> Recall that the ticket we are still debating over is from March 2016. > >> 2. Give QtWebEngine at least a try, let the users decide in a BETA phase. > >- a tiny percentage of users use Betas >- there already is quite some controversy in this email thread > > I don’t see why this should be a controversy. I understand and empathize with > the reaction from some of the community members, but I think as people who > have worked in this product and industry for a while, we should be able to > discuss this in a respectful, professional, clear headed manner. Maybe my use of the word “controversy” is wrong, but I didn’t mean that this should be anything disrespectful, unprofessional or hot-headed. So let me reformulate: Already in this email thread I do not see a broad consensus that using QtWebEngine for Qt Creator and Assistant would be desirable. >Br, Eike > >> 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 > >-- >Eike Ziller >Principal Software Engineer > >The Qt Company GmbH >Rudower Chaussee 13 >D-12489 Berlin >eike.zil...@qt.io >http://qt.io >Geschäftsführer: Mika Pälsi, >Juha Varelius, Mika Harjuaho >Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht > Charlottenburg, HRB 144331 B > > > > > > > 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 -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.zil...@qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der
Re: [Development] Assistant WebKit/WebEngine support
On 28.06.19, 12:22, "Eike Ziller" wrote: > From your response, I'm only gathering two options: There are other options. https://lists.qt-project.org/pipermail/development/2019-June/036712.html summarizes many of them. Additionally “strip down QtWebEngine or QtWebKit and support that”. Or, separating "plain and simple API documentation" to be displayed directly an Qt Creator/Assistant from “fancy tutorials” to be displayed by a browser of the user’s choice. Just curious, how would you define "plain and simple API documentation"? Developer documentation is split up into four categories: * API Reference -- the inline source code comments * Conceptual documentation -- The qdoc files that we use to explain how to use large modules * Code samples -- The snippets and the Examples * Strings -- error messages and Creator's strings Right now, with qdoc, all we have is "plain and simple API documentation", the first three categories. None of this is fancy yet Creator/Assistant can't display it correctly. > 1. Live with it and hope that somehow this will solve itself in the future -- there is no evidence from the past years that this is going to happen. Recall that the ticket we are still debating over is from March 2016. > 2. Give QtWebEngine at least a try, let the users decide in a BETA phase. - a tiny percentage of users use Betas - there already is quite some controversy in this email thread I don’t see why this should be a controversy. I understand and empathize with the reaction from some of the community members, but I think as people who have worked in this product and industry for a while, we should be able to discuss this in a respectful, professional, clear headed manner. Br, Eike > 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 -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.zil...@qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B 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
Re: [Development] Assistant WebKit/WebEngine support
> On Jun 28, 2019, at 10:56, Palaraja, Kavindra wrote: > > On 28.06.19, 10:24, "Eike Ziller" wrote: > >> On 27. Jun 2019, at 15:46, Palaraja, Kavindra wrote: >> >> On 27.06.19, 10:47, "Development on behalf of Jaroslaw Kobus" >> 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? >> > > .. > >Again, I’m not in principle against the above functionality, >but I don’t want us to pay the price that is imposed by a full-blown > QtWebEngine. If we cannot severely strip that down, that price is much higher > than necessary for HTML+CSS, and even for HTML+CSS+JavaScript. > > > To clarify, you are not against better functionality in how Creator displays > documentation. But: > > * It can't be QTextBrowser, because it's not a full-blown HTML viewer from > what I've seen in https://bugreports.qt.io/browse/QTBUG-6 > * It can't be QtWebEngine, because both you and Andre aren't willing to pay > the price I see some other critical voices in this email thread as well. > From your response, I'm only gathering two options: There are other options. https://lists.qt-project.org/pipermail/development/2019-June/036712.html summarizes many of them. Additionally “strip down QtWebEngine or QtWebKit and support that”. Or, separating "plain and simple API documentation" to be displayed directly an Qt Creator/Assistant from “fancy tutorials” to be displayed by a browser of the user’s choice. > 1. Live with it and hope that somehow this will solve itself in the future -- > there is no evidence from the past years that this is going to happen. Recall > that the ticket we are still debating over is from March 2016. > 2. Give QtWebEngine at least a try, let the users decide in a BETA phase. - a tiny percentage of users use Betas - there already is quite some controversy in this email thread Br, Eike > 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 -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.zil...@qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On 27/06/2019 21:02, Thiago Macieira wrote: On Thursday, 27 June 2019 01:07:45 PDT Konrad Rosenbaum wrote: Please also keep in mind that a fair number of developers use the same tool-chain (qdoc, assistant, QtHelp) to generate their own documentation - this means that assistant gets redistributed. Ah, but this is an issue: assistant. See the thread about co-installability of Qt 5 and Qt 6: is assistant as a standalone application still required? You're saying it is. Indeed it is required. Please don't take Assistant away from me entirely. https://lists.qt-project.org/pipermail/development/2019-June/036704.html Bastiaan. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
I will just chime in here to repeat one important point: Chromium receives fixes for security problems every few weeks, at least. We typically release new versions of Qt Creator much less frequently. We cannot expose an unsafe web browser to our users, at least not without risking some major feces/fan interaction. Do we want to give ourselves this kind of headache? I clearly don't. Furthermore, the approach of having a simplified documentation format for things like the "sidebar" style help view is rather appealing. I would even go and customize that further for the narrow width display you have there. I find myself constantly resizing the editor and help view when I view them side by side. Then I would throw out the whole "full window" help mode in Qt Creator and have people use a real web browser for that instead. Things like integrated interactive tutorials should maybe not be seen as part of the help system at all. You could write those using any technology. Widgets or QML for example. Ulf ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On 27.06.19 20:14, Thiago Macieira wrote: On Wednesday, 26 June 2019 18:47:32 PDT Lars Knoll wrote: Yes, Webengine uses some memory. But is that really a problem on developer machines? [...] I'm not saying that Qt Web Engine would be a problem. I was arguing against "memory is not a problem on developer machines". We still need to be careful of how much we use. Anyway, +150MB for Qt Creator is close to a 20% increase in how much it's consuming right now, with no C++ files open. I'm also seeing 1.2 GB swapped out... Right, not everybody has 16GB of ram. There are people wanting to use QtCreator also in poorer country, or simply students or non-pro, with cheaper hardware. Or sometimes even it can be convenient to debug with QtCreator running on the embedded target machine. Not saying anything pro or against QtWebEngine: Just saying that, in general, the "RAM is cheap anyway for developer" argument should not be a license to wasting memory. (A 20% increase is not negligible) ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On 28.06.19, 10:24, "Eike Ziller" wrote: > On 27. Jun 2019, at 15:46, Palaraja, Kavindra wrote: > > On 27.06.19, 10:47, "Development on behalf of Jaroslaw Kobus" 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? > .. Again, I’m not in principle against the above functionality, but I don’t want us to pay the price that is imposed by a full-blown QtWebEngine. If we cannot severely strip that down, that price is much higher than necessary for HTML+CSS, and even for HTML+CSS+JavaScript. To clarify, you are not against better functionality in how Creator displays documentation. But: * It can't be QTextBrowser, because it's not a full-blown HTML viewer from what I've seen in https://bugreports.qt.io/browse/QTBUG-6 * It can't be QtWebEngine, because both you and Andre aren't willing to pay the price From your response, I'm only gathering two options: 1. Live with it and hope that somehow this will solve itself in the future -- there is no evidence from the past years that this is going to happen. Recall that the ticket we are still debating over is from March 2016. 2. Give QtWebEngine at least a try, let the users decide in a BETA phase. 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
Re: [Development] Assistant WebKit/WebEngine support
> On Jun 28, 2019, at 10:24, Eike Ziller wrote: > > > >> On 27. Jun 2019, at 15:46, Palaraja, Kavindra wrote: >> >> On 27.06.19, 10:47, "Development on behalf of Jaroslaw Kobus" >> 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 > > That indeed probably uses JavaScript + fancy function call on the document > object. (Side note: That doesn’t mean that one couldn’t implement that > behavior with a no-JavaScript offline browser as well.) > >> 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 > > I don’t think such a combo box can be implemented offline the same as online, > since offline it is not predefined which versions are actually there (and > where). > >> 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. > > Actually I don’t like that I see the details of whatever step happens to be > at the top, instead of whatever step I’m actually interested in (which I > wouldn’t normally scroll to the top). Anyhow that might be personal > preference. > In any case IMO these kinds of tutorials do not have to show integrated into > the IDE. They work perfectly in an external browser (offline or online). (*) > What I think must be integrated into the IDE though is API documentation, so > things like context help and looking up API from the index works nicely. > > Interestingly I don’t find these features of Apple’s documentation (2+3) in > the documentation integrated into Xcode. There I only find a clean minimal > API documentation browser. When I e.g. click on links to examples an external > browser opens. > > (*) > Eclipse has (or had?) integrated tutorials with links / buttons that actually > perform actions in the IDE for you while you follow the tutorial. This would > be difficult online or in an external browser without the ability to register > special URL/scheme handlers. > If someone has interest I did some limited experiments in Qt Creator with > that here: https://codereview.qt-project.org/c/qt-creator/qt-creator/+/102110 > >> 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 > > 4+5 are covered by HTML+CSS without any dynamic or int
Re: [Development] Assistant WebKit/WebEngine support
> On 27. Jun 2019, at 15:46, Palaraja, Kavindra wrote: > > On 27.06.19, 10:47, "Development on behalf of Jaroslaw Kobus" > 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 That indeed probably uses JavaScript + fancy function call on the document object. (Side note: That doesn’t mean that one couldn’t implement that behavior with a no-JavaScript offline browser as well.) > 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 I don’t think such a combo box can be implemented offline the same as online, since offline it is not predefined which versions are actually there (and where). > 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. Actually I don’t like that I see the details of whatever step happens to be at the top, instead of whatever step I’m actually interested in (which I wouldn’t normally scroll to the top). Anyhow that might be personal preference. In any case IMO these kinds of tutorials do not have to show integrated into the IDE. They work perfectly in an external browser (offline or online). (*) What I think must be integrated into the IDE though is API documentation, so things like context help and looking up API from the index works nicely. Interestingly I don’t find these features of Apple’s documentation (2+3) in the documentation integrated into Xcode. There I only find a clean minimal API documentation browser. When I e.g. click on links to examples an external browser opens. (*) Eclipse has (or had?) integrated tutorials with links / buttons that actually perform actions in the IDE for you while you follow the tutorial. This would be difficult online or in an external browser without the ability to register special URL/scheme handlers. If someone has interest I did some limited experiments in Qt Creator with that here: https://codereview.qt-project.org/c/qt-creator/qt-creator/+/102110 > 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 4+5 are covered by HTML+CSS without any dynamic or interactive capabilities. Again, I’m not in principle against the above functionality, but I don’t want us to pay the price that is imposed by a full-blown QtWebEngine. If we cannot severely s
Re: [Development] Assistant WebKit/WebEngine support
>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. But we can package the full Qt documentation as an add-on module. Then if you don't want to be online, you can install the Qt documentation add-on. The Qt documentation site/add-on then just needs an index of all the snippets Creator might need to load. From: Samuel Gaist Sent: Friday, June 28, 2019 8:25 AM To: Martin Smith Cc: Palaraja, Kavindra; development@qt-project.org Subject: Re: [Development] Assistant WebKit/WebEngine support > On 28 Jun 2019, at 07:59, Martin Smith 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 on behalf of Palaraja, > Kavindra > Sent: Friday, June 28, 2019 7:40 AM > To: development@qt-project.org > Subject: Re: [Development] Assistant WebKit/WebEngine support > > On 27.06.19, 20:59, "Development on behalf of André Pönitz" > 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 l
Re: [Development] Assistant WebKit/WebEngine support
> On 28 Jun 2019, at 07:59, Martin Smith 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 on behalf of Palaraja, > Kavindra > Sent: Friday, June 28, 2019 7:40 AM > To: development@qt-project.org > Subject: Re: [Development] Assistant WebKit/WebEngine support > > On 27.06.19, 20:59, "Development on behalf of André Pönitz" > 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
Re: [Development] Assistant WebKit/WebEngine support
>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? From: Development on behalf of Palaraja, Kavindra Sent: Friday, June 28, 2019 7:40 AM To: development@qt-project.org Subject: Re: [Development] Assistant WebKit/WebEngine support On 27.06.19, 20:59, "Development on behalf of André Pönitz" 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@qt-project.org https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On 27.06.19, 20:59, "Development on behalf of André Pönitz" 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@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
> On Jun 27, 2019, at 16:55, Simon Hausmann wrote: > > > Am 26.06.19 um 14:44 schrieb Kirill Burtsev: >> Hi, >> >> sorry, but that is not a right way to assess thing like memory consumption. >> >> Windows shows in a task manager just private memory (can not be used >> by other processes) usage for process. And that is really takes 15-20 Mb >> but just for separate renderer process. Main process (in case for example >> simplebrowser or minimal) needs around 30Mb of its own private memory >> and +5Mb for every renderer process (basically page by default). > > > You're right, I did not account for the qt creator process. Here's what > I see when starting a blank creator and loading the QWidget > documentation (that was a famous test-case when we developed QTextDocument): > > > * When using QTextBrowser, the creator process takes about 91 MB of RAM > > * When using QWebEngine, the creator process grows to 109 MB and 25 > MB of private RAM for the web engine process. > > > That's an overhead of 43 MB of RAM for showing the QWidget reference > documentation compared to QTextBrowser. > > >> And there is also shared memory for all these processes (library itself, >> which is over 100Mb for webengine, and other resources): 40Mb for main >> process itself and then it goes to 80-90 with spawned rendereres. One can >> see all these numbers inside extended columns for shared/private/workingset >> memory inside detailed tab of a 'Task Manager', 'Resource Monitor' builtin >> tools or simple ProcessHacker guitool for Windows. > > > I'm aware of shared memory, and I'm deliberately excluding it. The bulk > of the shared pages are mapped from disk (DLLs) and can be discarded by > the kernel when for example the doc view is not visible in creator and > the kernel is low on memory (like when compiling). It's indeed the > private memory that hurts the users and that would have to be swapped to > disk in case of shortages. > > >> So, for example, in case of offline html version of cppreference doc for c++: >> https://en.cppreference.com/w/Cppreference:Archives >> with 6 pages opened for basic_ostream it takes about this amount of memory: >> 30 + 6 * 5 + 15 * 6 + 80 = 230Mb > > Isn't counting for 6 open pages a bit of an unrealistic scenario? In > creator typically there's only one page of documentation visible at a time. A common number of open pages if you do not do anything special is 3, as I wrote in my mail where I did my own assessment of ~70MB per open page on macOS. Context help + Help mode + external window. But we _do_ have the feature of opening new “tabs” in help mode, and these are restored at Qt Creator startup, so it is actually not unrealistic to assume that people have more than 3 viewer instances at the same time. -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.zil...@qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
27.06.2019, 22:15, "André Pönitz" : > On Thu, Jun 27, 2019 at 06:57:08AM +0200, Richard Weickelt wrote: >> Is it well known, how many QtCreator users are even using the integrated >> help functionality? How many Qt users are using QtAssistant and how many >> prefer the online documentation? > > The exact numbers are not known (to me), but the patterns as such are in > principle. It is known that effectively the full range of possibilities > starting from reading the doc comments in Qt sources up to online docs > only are used in practice. > > And it is known that no matter what option is selected as "the only > true one" some people will be left out. > >> I stopped using the integrated help and QtAssisant at some point and now I >> am exclusively using the online documentation in my regular browser. I can't >> give an exact reason, but I can see a correlation of multiple things: >> >> 1) Fast internet access became available everywhere I worked and there >> was no noticable delay anymore in page loading. >> 2) I am reading so much in the browser anyway that I feel more >> comfortable also reading the Qt docs in it. >> 3) I am using my browser anyway while working with Qt because >> I often search in the mailing list, forum, other docs, etc. >> 4) Using a regular search engine leads to good-enough search results >> and is very fast >> 5) There was the point where Qt's online docs started to look better. >> Cripser fonts, more whitespace, better code highlighting. >> >> I guess no matter how hard you try and how much effort you put into it, I'll >> probably never use QtCreator's integrated help again. > > That's a valid usage pattern. > >> I'd rather appreciate >> QtCreator to be slim and fast, both when using and building it. I think the >> time, energy should rather be spend in improving the documentation as a >> whole. I'd like to see more video tutorials about QtCreator best practices, >> for instance. > > I usuall run a mixture of online docs and reading the comments directly, > except in the occasional off-line case where it is QTextBrowser and/or > comments. > >> And yes, I (and a lot of users) would appreciate if qdoc would output >> exactly the same nice html design as doc.qt.io. > > And as usual, beauty is in the eye of the beholder. E.g. I still dislike > the current Qt Green, especially as text color. And unfortunately for me > in that case the rate of change of design seems to have slowed down > lately in that area;&} Be my guest. With QtWebKit you can set user style sheet [1] to override those properties that you don't like, e.g. change green color to something else. And this does not even require enabling JS support for the page. [1] https://qtwebkit.github.io/doc/qtwebkit/qwebsettings.html#setUserStyleSheetUrl -- Regards, Konstantin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On Thu, Jun 27, 2019 at 06:57:08AM +0200, Richard Weickelt wrote: > Is it well known, how many QtCreator users are even using the integrated > help functionality? How many Qt users are using QtAssistant and how many > prefer the online documentation? The exact numbers are not known (to me), but the patterns as such are in principle. It is known that effectively the full range of possibilities starting from reading the doc comments in Qt sources up to online docs only are used in practice. And it is known that no matter what option is selected as "the only true one" some people will be left out. > I stopped using the integrated help and QtAssisant at some point and now I > am exclusively using the online documentation in my regular browser. I can't > give an exact reason, but I can see a correlation of multiple things: > > 1) Fast internet access became available everywhere I worked and there >was no noticable delay anymore in page loading. > 2) I am reading so much in the browser anyway that I feel more >comfortable also reading the Qt docs in it. > 3) I am using my browser anyway while working with Qt because >I often search in the mailing list, forum, other docs, etc. > 4) Using a regular search engine leads to good-enough search results >and is very fast > 5) There was the point where Qt's online docs started to look better. >Cripser fonts, more whitespace, better code highlighting. > > I guess no matter how hard you try and how much effort you put into it, I'll > probably never use QtCreator's integrated help again. That's a valid usage pattern. > I'd rather appreciate > QtCreator to be slim and fast, both when using and building it. I think the > time, energy should rather be spend in improving the documentation as a > whole. I'd like to see more video tutorials about QtCreator best practices, > for instance. I usuall run a mixture of online docs and reading the comments directly, except in the occasional off-line case where it is QTextBrowser and/or comments. > And yes, I (and a lot of users) would appreciate if qdoc would output > exactly the same nice html design as doc.qt.io. And as usual, beauty is in the eye of the beholder. E.g. I still dislike the current Qt Green, especially as text color. And unfortunately for me in that case the rate of change of design seems to have slowed down lately in that area;&} Andre' ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On Thursday, 27 June 2019 01:07:45 PDT Konrad Rosenbaum wrote: > Just to make sure I just installed Qt 5.13 for MinGW 7.3 on my Windows > VM - WebEngine is nowhere to be seen. (Sorry, I don't have enough > capacity to check whether I might be able to compile it myself using clang.) You don't need Qt Creator and Qt Web Engine compiled with the same compiler that you use for your own application. Since there's at least one compiler supporting Qt Web Engine on Window, we should conclude that Windows is supported. But: > Please also keep in mind that a fair number of developers use the same > tool-chain (qdoc, assistant, QtHelp) to generate their own documentation > - this means that assistant gets redistributed. Ah, but this is an issue: assistant. See the thread about co-installability of Qt 5 and Qt 6: is assistant as a standalone application still required? You're saying it is. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On Thu, Jun 27, 2019 at 01:47:32AM +, Lars Knoll wrote: > Yes, Webengine uses some memory. But is that really a problem on > developer machines? On three out of four machines that I use with Qt Creator regularly have limitations that make the presence of WebEngine undesirable. These three might not qualify as "developer machines" for you, but I actually use them for development. > 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. > 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. If I were to design my Qt application in a way that I created GUI elements outside the GUI thread, or wanted templates as QObjects, or maybe needed copiable QObjects, and reported failure here I am fairly sure the reaction would not be Deus ex Machina declaring "Let there be threads! Let there be objects!", but rather some more or less polite but explicit hint that this is my fault. > This is frustrating to those people who are trying to create as good > as possible documentation for Qt and leads to us having worse quality > documentation than we could. > > Using Qt Webengine to render the docs is a rather straightforward > and easy solution to this problem. No. See below. > The additional memory usage is a rather small price to pay I'd even let that pass based on Simon's "14-20 MB RAM" number, even in my "development" setups. Strangely enough that's not what other people see. > for better usability of our docs, giving our > technical writers more options and simplifying their lives. The "usabilty" in question here was - table backgrounds via CSS for a submodule (which (a) would make it inconsistent with the rest of Qt doc tables, and if I got it right would (b) in principle be doable with QTextBrowser if done properly) - missing table borders, which are possibly "just" a bug. So no. Not even with the 14-20 MB RAM price tag. Regarding the "easy solution to this problem": You failed to address the problem of security. The limitations of QTextBrowser are actually a huge advantage in this area: You can't break it *that* easily. With a full webbrowser there are essentially two basic options when it comes to security: 1. The "always online, always update" scenario. The drawbacks here are: - It's not how quite a few people do and want to use it - We are simply lacking the ability to create ad-hoc releases on short notice, leaving users vulnerable - We will lose the currently existing ability to drop features with high maintainance effort but small user base by telling the remaining users to simply stick with an older version (which works surprisingly well in practice) 2. The "cut down to the bare bones" HTML+CSS renderer to get a similar attack surface as QTextBrowser. - This is far from being a "full browser" anymore, some of the claimed advantages will not be available anymore - It takes effort to patch and maintain the patch - It takes effort to check that the reaining code is indeed not vulnerable. The days that Chromium downloads binary blobs on startup might be over, but that's something to verify on each update. Of course there's also middleground, with a respective mixture of drawbacks. So which one would be exactly the one you just decreed as "easy solution"? > Qt used to make a point on having superior documentation to most other > frameworks, That's still true at least for the core modules, and the point has traditionally been made on the actual contents of the docs, not on table borders, stuttering animations, or chunks of JaveScript trying to call home to Google - to name just few of the advantages of the current online help that apparently serves as benchmark here. > and it was (and still is) one of the reasons for its success. And, surprise!, the use of QTextBrowser wasn't a problem for this success. > Whatever we can do to help make the documentation better is something > I think we should do. When benefits outweigh costs. Not at any price. Andre'
Re: [Development] Assistant WebKit/WebEngine support
Hi, On 6/27/19 3:47 AM, Lars Knoll wrote: > > Yes, Webengine uses some memory. But is that really a problem on developer > machines? It is a problem, but IMHO not the main problem. The main problem is that WebEngine is not available on all platforms that are supported (as a development host) by Qt. Just to make sure I just installed Qt 5.13 for MinGW 7.3 on my Windows VM - WebEngine is nowhere to be seen. (Sorry, I don't have enough capacity to check whether I might be able to compile it myself using clang.) Please also keep in mind that a fair number of developers use the same tool-chain (qdoc, assistant, QtHelp) to generate their own documentation - this means that assistant gets redistributed. One of my biggest Applications is 15MB on its own, 74MB including Qt and all remotely necessary plugins. Adding WebEngine adds 115MB, assistant itself is a mere 18MB. Please do not expect me to like this, having to accept it is enough... > 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. ...as I wrote earlier - none of the possible solutions are ideal. Someone has to invest some work somewhere. QTextBrowser, WebEngine or Technical Writing - make a choice. Chose wisely! ;) Konrad ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On Thursday, 27 June 2019 07:39:29 PDT Lars Knoll wrote: > > On 27 Jun 2019, at 08:25, Thiago Macieira > > wrote: > > On Wednesday, 26 June 2019 18:47:32 PDT Lars Knoll wrote: > >> Yes, Webengine uses some memory. But is that really a problem on > >> developer > >> machines? > > > > > > Yes. I have 16 GB of RAM and 16 GB of swap. Sometimes Linux fails to > > suspend to disk unless I quit either Creator, Firefox or Chromium. > > Free memory isn't completely the issue. Even with 6 GB free (after > > re-adding buffers/cache) and 10 GB swap free, the suspend can fail. > > I don’t buy this.Qt Webengine (one page) takes let’s say worst case 150M (I > would believe it’s quite a bit less). That’s less than 1% of your available > RAM. I'm not saying that Qt Web Engine would be a problem. I was arguing against "memory is not a problem on developer machines". We still need to be careful of how much we use. Anyway, +150MB for Qt Creator is close to a 20% increase in how much it's consuming right now, with no C++ files open. I'm also seeing 1.2 GB swapped out... > > [*] KMail already starts a QtWebEngineProcess, but the main process is > > right now consuming 950 MB of heap. > > The complain to the KMail developers :) Indeed. Anyway, closing and restarting both applications, KMail dropped to a mere 310 MB heap (530 MB RSS) and Qt Creator increased to 980 MB RSS (but no swap). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
Am 26.06.19 um 14:44 schrieb Kirill Burtsev: > Hi, > > sorry, but that is not a right way to assess thing like memory consumption. > > Windows shows in a task manager just private memory (can not be used > by other processes) usage for process. And that is really takes 15-20 Mb > but just for separate renderer process. Main process (in case for example > simplebrowser or minimal) needs around 30Mb of its own private memory > and +5Mb for every renderer process (basically page by default). You're right, I did not account for the qt creator process. Here's what I see when starting a blank creator and loading the QWidget documentation (that was a famous test-case when we developed QTextDocument): * When using QTextBrowser, the creator process takes about 91 MB of RAM * When using QWebEngine, the creator process grows to 109 MB and 25 MB of private RAM for the web engine process. That's an overhead of 43 MB of RAM for showing the QWidget reference documentation compared to QTextBrowser. > And there is also shared memory for all these processes (library itself, > which is over 100Mb for webengine, and other resources): 40Mb for main > process itself and then it goes to 80-90 with spawned rendereres. One can > see all these numbers inside extended columns for shared/private/workingset > memory inside detailed tab of a 'Task Manager', 'Resource Monitor' builtin > tools or simple ProcessHacker guitool for Windows. I'm aware of shared memory, and I'm deliberately excluding it. The bulk of the shared pages are mapped from disk (DLLs) and can be discarded by the kernel when for example the doc view is not visible in creator and the kernel is low on memory (like when compiling). It's indeed the private memory that hurts the users and that would have to be swapped to disk in case of shortages. > So, for example, in case of offline html version of cppreference doc for c++: > https://en.cppreference.com/w/Cppreference:Archives > with 6 pages opened for basic_ostream it takes about this amount of memory: > 30 + 6 * 5 + 15 * 6 + 80 = 230Mb Isn't counting for 6 open pages a bit of an unrealistic scenario? In creator typically there's only one page of documentation visible at a time. Simon ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
> On 27 Jun 2019, at 08:25, Thiago Macieira wrote: > > On Wednesday, 26 June 2019 18:47:32 PDT Lars Knoll wrote: >> Yes, Webengine uses some memory. But is that really a problem on developer >> machines? > > Yes. I have 16 GB of RAM and 16 GB of swap. Sometimes Linux fails to suspend > to disk unless I quit either Creator, Firefox or Chromium. Free memory isn't > completely the issue. Even with 6 GB free (after re-adding buffers/cache) and > 10 GB swap free, the suspend can fail. I don’t buy this.Qt Webengine (one page) takes let’s say worst case 150M (I would believe it’s quite a bit less). That’s less than 1% of your available RAM. The reason the browser is an issue is maybe because many developers tend to have hundreds of tabs open. > > Another issue is starting a VM. There are many things in our corporate > network > that require a Windows, plus of course doing testing with MSVC. The moment > you > have a 4GB+ VM running, Creator, Firefox, Chromium and KMail[*], it adds up. > > So, yes, even on a developer's machine we shouldn't use too much. > > [*] KMail already starts a QtWebEngineProcess, but the main process is right > now consuming 950 MB of heap. The complain to the KMail developers :) Cheers, Lars ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
> On 27 Jun 2019, at 16:03, Alberto Mardegan > wrote: > > On 27/06/19 14:14, Bastiaan Veelo wrote: >> >> However, it seems that most web browsers that implemented their own >> browser tech have ditched those in favour of a third party framework >> (see Opera, Edge, e.g.) -- how much of the reason for that is due to >> rendering or networking I don't know. > > I would guess that Javascript and security issues also played a big role. > But if we took LiteHtml as a base (as Eike suggested) and just focused > on good HTML+CSS support, we could make a very useful and safe widget. And does anybody know how well that works? Who’s taking the responsibility to fix bugs in it that will get reported? Cheers, Lars ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
> On 27 Jun 2019, at 11:25, Bastiaan Veelo wrote: > > On 27/06/2019 06:57, Richard Weickelt wrote: >>> Qt used to make a point on having superior documentation to most other >>> frameworks, and it was (and still is) one of the reasons for its success. >>> Whatever we can do to help make the documentation better is something I >>> think we should do. > [...] >> I stopped using the integrated help and QtAssisant at some point and now I >> am exclusively using the online documentation in my regular browser. I can't >> give an exact reason, but I can see a correlation of multiple things: > [...] >> 5) There was the point where Qt's online docs started to look better. >>Cripser fonts, more whitespace, better code highlighting. >> >> I guess no matter how hard you try and how much effort you put into it, I'll >> probably never use QtCreator's integrated help again. > > You just listed one of the deficiencies of QTextBrowser as a reason to not > use Qt for browsing its documentation. That's like saying it's bad, so there > is no point in making it good. QTextBrowser was never meant as a full HTML5 rendering engine, and it will never be. I honestly don’t think implementing (close to) full CSS 2.1 support for it makes a lot of sense. I’ve implemented CSS 2.1 support for KHTML way back and adding that to QTextBrowser is a huge job. And since we have something that can render HTML5 perfectly it doesn’t make sense to do all that work. Lars ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On 27/06/19 14:14, Bastiaan Veelo wrote: > > However, it seems that most web browsers that implemented their own > browser tech have ditched those in favour of a third party framework > (see Opera, Edge, e.g.) -- how much of the reason for that is due to > rendering or networking I don't know. I would guess that Javascript and security issues also played a big role. But if we took LiteHtml as a base (as Eike suggested) and just focused on good HTML+CSS support, we could make a very useful and safe widget. Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On 27.06.19, 10:47, "Development on behalf of Jaroslaw Kobus" 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-6 -- 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 rea
Re: [Development] Assistant WebKit/WebEngine support
A very good post, thank you Jarek. Ideally, Qt would have a dedicated HTML renderer that works on all platforms, without unnecessary overhead and security issues. Possibly as a new widget (QHtmlBrowser) to keep QTextBrowser strictly rich text, possibly removing features from QTextBrowser to make it truly minimal. The Qt Company, inventors of QML, should be in a good position to accomplish such a stand alone HTML browser. However, it seems that most web browsers that implemented their own browser tech have ditched those in favour of a third party framework (see Opera, Edge, e.g.) -- how much of the reason for that is due to rendering or networking I don't know. Either way, accomplishing decent standard compliance will require a major investment. A business decision should be made whether that investment isn't better spent on teaming up with a third party to make its framework modular, so that it is capable of working optimally for offline content. If that is implemented well, this could potentially mean that on the platforms that use this framework for their native browser, QHtmlBrowser could simply forward to the system shared library for HTML rendering (without networking). Gecko, WebKit and Chromium seem to be the major browser back ends. Which of those is best to team up with? Both WebKit and Chromium are derived from KHTML, so maybe KHTML is a good starting point due to its relation with Qt. Or, if WebKit and Chromium aren't easily modularised, maybe that is because of how KHTML is put together, and a fresh look at Gecko is beneficial? I agree with Jarek that Qt should plan long term and implement the best solution, not the easiest or quickest. It has been bad for four years already, a year or two more is not a big deal. People that require Assistant with full HTML/CSS capability can get that easily today[1], and can wait. Bastiaan. [1] https://github.com/veelo/qttools ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On Tue, Jun 25, 2019 at 3:12 PM Giuseppe D'Angelo via Development wrote: > Are you referring to the 1px table wrapping the list of members, etc.? > > Saying that we want to move to a full blown browser for that makes me > think that this is a case of Qt not eating its own dogfood. Is it > impossible to fix QTextDocument to support them properly? QTextDocument is sensitive code, users will report regressions if anything is 1px off compared to previous Qt version. All this risk for the sake of docs ? Even if we started adding features, where do we stop, where's the cut-off ? People will want more and more, until it's a full blown browser. I think it could be easier to remove most of the unneeded features from QtWebKit than to add the missing ones to QTextDocument. Regards, Sergio Martins ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On 27/06/2019 06:57, Richard Weickelt wrote: Qt used to make a point on having superior documentation to most other frameworks, and it was (and still is) one of the reasons for its success. Whatever we can do to help make the documentation better is something I think we should do. [...] I stopped using the integrated help and QtAssisant at some point and now I am exclusively using the online documentation in my regular browser. I can't give an exact reason, but I can see a correlation of multiple things: [...] 5) There was the point where Qt's online docs started to look better. Cripser fonts, more whitespace, better code highlighting. I guess no matter how hard you try and how much effort you put into it, I'll probably never use QtCreator's integrated help again. You just listed one of the deficiencies of QTextBrowser as a reason to not use Qt for browsing its documentation. That's like saying it's bad, so there is no point in making it good. Bastiaan. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On Thu, 27 Jun 2019 08:47:07 +0300 Alberto Mardegan wrote: > On 27/06/19 04:47, Lars Knoll wrote: > > > > Yes, Webengine uses some memory. But is that really a problem on developer > > machines? > > Yes. The more RAM you use for surfing documentation, the less RAM you > have for building. I have 16 GB of RAM, and sometimes I have to close > Chromium away (yes, I know, my fault, I should use a more lightweight > browser!). Doing the same with QtCreator (which I only use for browsing > documentation, not for actual development) would be quite troublesome. Speaking of more light-weight applications: You probably should be using assistant instead. Christian ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
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. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On 6/27/19 3:47 AM, Lars Knoll wrote: >> On 26 Jun 2019, at 23:16, Eike Ziller wrote: >> >> >> >>> On 26. Jun 2019, at 13:47, Simon Hausmann wrote: >>> >>> Hi, >>> >>> From my earlier email: >>> >>> " I measured on Windows with a Qt Creator built with >>> WebEngine support and surfed a little through the docs. The memory >>> consumption of the web engine process weighed in between 14-20 MB of RAM.” >> >> From Activity Monitor on macOS, it looks like here the memory consumption >> increase compared to QTextBrowser is about >> 40 MB for the Qt Creator process + 20-40 MB for the QtWebEngineProcess >> >> per simultaneously opened page. >> >> So, that is something like a 140 MB RAM increase if you don’t explicitly >> open documentation in additional “tabs”, >> since by default we have one viewer for context help beside the editor, and >> the viewer in Help mode. >> If you additionally show some documentation in an external window (happens >> when opening examples), that’s about 210 MB RAM usage increase then. > > Yes, Webengine uses some memory. But is that really a problem on developer > machines? > > 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. I would expect a rather limited feature set for displaying documentation. So I'm wondering whether/how the requirements changed for that in e.g. the last years? > 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. This is frustrating to those people who are trying to create > as good as possible documentation for Qt and leads to us having worse quality > documentation than we could. > > Using Qt Webengine to render the docs is a rather straightforward and easy > solution to this problem. The additional memory usage is a rather small price > to pay for better usability of our docs, giving our technical writers more > options and simplifying their lives. > > Qt used to make a point on having superior documentation to most other > frameworks, and it was (and still is) one of the reasons for its success. > Whatever we can do to help make the documentation better is something I think > we should do. > > Cheers, > Lars > >> >> Br, Eike >> >>> That number came from the task manager in Windows. >>> >>> Simon >>> From: Development on behalf of Michal >>> Klocek >>> Sent: Wednesday, June 26, 2019 13:31 >>> To: development@qt-project.org >>> Subject: Re: [Development] Assistant WebKit/WebEngine support >>> >>> Could you explain how did you measure web engine memory consumption to >>> get 14-20MB of ram ? >>> >>> On 6/26/19 1:12 PM, Simon Hausmann wrote: >>>> >>>> Am 25.06.19 um 23:53 schrieb Konrad Rosenbaum: >>>>> 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) >>>> >>>> >>>> I'd really like to eliminate this myth of a "horrible memory footprint". >>>> I sent an email earlier in this thread regarding this and presented >>>> numbers that suggest otherwise for documentation content. >>>> >>>> >>>> >>>> Simon >>>> >>>> >>>> ___ >>>> Development mailing list >>>> Development@qt-project.org >>>> https://lists.qt-project.org/listinfo/development >>>> >>> ___ >>> Development mailing list >>> Development@qt-project.org >>> https://lists.qt-project.org/listinfo/develop
Re: [Development] Assistant WebKit/WebEngine support
On Wednesday, 26 June 2019 18:47:32 PDT Lars Knoll wrote: > Yes, Webengine uses some memory. But is that really a problem on developer > machines? Yes. I have 16 GB of RAM and 16 GB of swap. Sometimes Linux fails to suspend to disk unless I quit either Creator, Firefox or Chromium. Free memory isn't completely the issue. Even with 6 GB free (after re-adding buffers/cache) and 10 GB swap free, the suspend can fail. Another issue is starting a VM. There are many things in our corporate network that require a Windows, plus of course doing testing with MSVC. The moment you have a 4GB+ VM running, Creator, Firefox, Chromium and KMail[*], it adds up. So, yes, even on a developer's machine we shouldn't use too much. [*] KMail already starts a QtWebEngineProcess, but the main process is right now consuming 950 MB of heap. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On 27/06/19 04:47, Lars Knoll wrote: > > Yes, Webengine uses some memory. But is that really a problem on developer > machines? Yes. The more RAM you use for surfing documentation, the less RAM you have for building. I have 16 GB of RAM, and sometimes I have to close Chromium away (yes, I know, my fault, I should use a more lightweight browser!). Doing the same with QtCreator (which I only use for browsing documentation, not for actual development) would be quite troublesome. IMHO a better question would be: are the costs of using QtWebEngine worth the benefits? > 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. We can switch to something else in the future; switching to QtWebEngine is easy. But in the meantime, all improvement made to QTextBrowser (or any development done on a new lightweight HTML view component) will be a great benefit to the Qt developer community: many applications could benefit from with, typically for showing inline docs. Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
> Qt used to make a point on having superior documentation to most other > frameworks, and it was (and still is) one of the reasons for its success. > Whatever we can do to help make the documentation better is something I > think we should do. Is it well known, how many QtCreator users are even using the integrated help functionality? How many Qt users are using QtAssistant and how many prefer the online documentation? I stopped using the integrated help and QtAssisant at some point and now I am exclusively using the online documentation in my regular browser. I can't give an exact reason, but I can see a correlation of multiple things: 1) Fast internet access became available everywhere I worked and there was no noticable delay anymore in page loading. 2) I am reading so much in the browser anyway that I feel more comfortable also reading the Qt docs in it. 3) I am using my browser anyway while working with Qt because I often search in the mailing list, forum, other docs, etc. 4) Using a regular search engine leads to good-enough search results and is very fast 5) There was the point where Qt's online docs started to look better. Cripser fonts, more whitespace, better code highlighting. I guess no matter how hard you try and how much effort you put into it, I'll probably never use QtCreator's integrated help again. I'd rather appreciate QtCreator to be slim and fast, both when using and building it. I think the time, energy should rather be spend in improving the documentation as a whole. I'd like to see more video tutorials about QtCreator best practices, for instance. And yes, I (and a lot of users) would appreciate if qdoc would output exactly the same nice html design as doc.qt.io. The current output is so ugly (Doxygen is even worse) that I even prefer to write API documentation directly in rST/Sphinx. Best regards Richard ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
> On 26 Jun 2019, at 23:16, Eike Ziller wrote: > > > >> On 26. Jun 2019, at 13:47, Simon Hausmann wrote: >> >> Hi, >> >> From my earlier email: >> >>" I measured on Windows with a Qt Creator built with >> WebEngine support and surfed a little through the docs. The memory >> consumption of the web engine process weighed in between 14-20 MB of RAM.” > > From Activity Monitor on macOS, it looks like here the memory consumption > increase compared to QTextBrowser is about > 40 MB for the Qt Creator process + 20-40 MB for the QtWebEngineProcess > > per simultaneously opened page. > > So, that is something like a 140 MB RAM increase if you don’t explicitly open > documentation in additional “tabs”, > since by default we have one viewer for context help beside the editor, and > the viewer in Help mode. > If you additionally show some documentation in an external window (happens > when opening examples), that’s about 210 MB RAM usage increase then. Yes, Webengine uses some memory. But is that really a problem on developer machines? 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. 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. This is frustrating to those people who are trying to create as good as possible documentation for Qt and leads to us having worse quality documentation than we could. Using Qt Webengine to render the docs is a rather straightforward and easy solution to this problem. The additional memory usage is a rather small price to pay for better usability of our docs, giving our technical writers more options and simplifying their lives. Qt used to make a point on having superior documentation to most other frameworks, and it was (and still is) one of the reasons for its success. Whatever we can do to help make the documentation better is something I think we should do. Cheers, Lars > > Br, Eike > >> That number came from the task manager in Windows. >> >> Simon >> From: Development on behalf of Michal >> Klocek >> Sent: Wednesday, June 26, 2019 13:31 >> To: development@qt-project.org >> Subject: Re: [Development] Assistant WebKit/WebEngine support >> >> Could you explain how did you measure web engine memory consumption to >> get 14-20MB of ram ? >> >> On 6/26/19 1:12 PM, Simon Hausmann wrote: >>> >>> Am 25.06.19 um 23:53 schrieb Konrad Rosenbaum: >>>> 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) >>> >>> >>> I'd really like to eliminate this myth of a "horrible memory footprint". >>> I sent an email earlier in this thread regarding this and presented >>> numbers that suggest otherwise for documentation content. >>> >>> >>> >>> Simon >>> >>> >>> ___ >>> Development mailing list >>> Development@qt-project.org >>> https://lists.qt-project.org/listinfo/development >>> >> ___ >> Development mailing list >> Development@qt-project.org >> https://lists.qt-project.org/listinfo/development >> ___ >> Development mailing list >> Development@qt-project.org >> https://lists.qt-project.org/listinfo/development > > -- > Eike Ziller > Principal Software Engineer > > The Qt Company GmbH > Rudower Chaussee 13 > D-12489 Berlin > eike.zil...@qt.io > http://qt.io > Geschäftsführer: Mika Pälsi, > Juha Varelius, Mika Harjuaho > Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, > HRB 144331 B > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On Tue, Jun 25, 2019 at 08:58:07PM +, Tor Arne Vestbø wrote: > > > > On 25 Jun 2019, at 22:53, André Pönitz wrote: > > > > On Tue, Jun 25, 2019 at 07:59:16PM +, Tor Arne Vestbø wrote: > >>> On 25 Jun 2019, at 21:30, Konrad Rosenbaum 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. > > > > I find it actually quite helpful and to the point. > > Huh? You find straw-men helpful and to the point? Depends on circumstances, but generally, yes. I assume the straw-men here is the insinuated intention to "win a design price", that's of course not the real intention, that was rather about being able to specify table background by CSS and table borders. However, the straw-men here is only the motivation, the actual technical effect on resource consumption and locking out users is the same. If one considers "locking out user for winning a design price" an outrageously bad deal, the straw-men arguments helps to understand that while "be able to use CSS for styling for table layouts at the price of locking out users" is not _exactly_ the same, it is still a _really bad_ deal. So I think the straw-men argument here indeed helps to get the order of magnitudes of gain and pain right. Without such "help" and unavailability of other measures humans tend to simply use the _number_ of presented arguments as a measure of their weight, i.e. "CSS for table background" counts the same (namely "one argument") as "locking out users". And when "draws table borders" is added, that's already a clear 2:1 win. Andre' ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
> On 26. Jun 2019, at 13:47, Simon Hausmann wrote: > > Hi, > > From my earlier email: > > " I measured on Windows with a Qt Creator built with > WebEngine support and surfed a little through the docs. The memory > consumption of the web engine process weighed in between 14-20 MB of RAM.” From Activity Monitor on macOS, it looks like here the memory consumption increase compared to QTextBrowser is about 40 MB for the Qt Creator process + 20-40 MB for the QtWebEngineProcess per simultaneously opened page. So, that is something like a 140 MB RAM increase if you don’t explicitly open documentation in additional “tabs”, since by default we have one viewer for context help beside the editor, and the viewer in Help mode. If you additionally show some documentation in an external window (happens when opening examples), that’s about 210 MB RAM usage increase then. Br, Eike > That number came from the task manager in Windows. > > Simon > From: Development on behalf of Michal > Klocek > Sent: Wednesday, June 26, 2019 13:31 > To: development@qt-project.org > Subject: Re: [Development] Assistant WebKit/WebEngine support > > Could you explain how did you measure web engine memory consumption to > get 14-20MB of ram ? > > On 6/26/19 1:12 PM, Simon Hausmann wrote: > > > > Am 25.06.19 um 23:53 schrieb Konrad Rosenbaum: > >> 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) > > > > > > I'd really like to eliminate this myth of a "horrible memory footprint". > > I sent an email earlier in this thread regarding this and presented > > numbers that suggest otherwise for documentation content. > > > > > > > > Simon > > > > > > ___ > > Development mailing list > > Development@qt-project.org > > https://lists.qt-project.org/listinfo/development > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.zil...@qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
Yes, we never felt the styles should be exactly same, but the most suitable for each purpose. Leena Date: Wed, 26 Jun 2019 11:39:18 + From: Christian Kandeler To: "development@qt-project.org" Subject: Re: [Development] Assistant WebKit/WebEngine support Message-ID: <20190626133856.518e070a@ckandeler-archlinux> Content-Type: text/plain; charset="utf-8" On Wed, 26 Jun 2019 11:24:30 + Riitta-Leena Miettinen wrote: > 3. Should the same style be used online and offline? > > For 3), we always answered „yes“, because we felt that the use cases for > reading documentation on the web or using it within Qt Creator next to the > Code editor were different. Just for clarification: I assume you meant "no" here? Christian ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
Hi, sorry, but that is not a right way to assess thing like memory consumption. Windows shows in a task manager just private memory (can not be used by other processes) usage for process. And that is really takes 15-20 Mb but just for separate renderer process. Main process (in case for example simplebrowser or minimal) needs around 30Mb of its own private memory and +5Mb for every renderer process (basically page by default). And there is also shared memory for all these processes (library itself, which is over 100Mb for webengine, and other resources): 40Mb for main process itself and then it goes to 80-90 with spawned rendereres. One can see all these numbers inside extended columns for shared/private/workingset memory inside detailed tab of a 'Task Manager', 'Resource Monitor' builtin tools or simple ProcessHacker guitool for Windows. So, for example, in case of offline html version of cppreference doc for c++: https://en.cppreference.com/w/Cppreference:Archives with 6 pages opened for basic_ostream it takes about this amount of memory: 30 + 6 * 5 + 15 * 6 + 80 = 230Mb Single process mode will make it a little bit better but still in a hundreds range. Btw, those who interested in displaying simple html pages with webengine and its memory costs could look at a practical application inside KDE: 'System Monitor' builtin tool there for looking at system processes and stats uses QtWebEngine by displaying simple fancy looking html for 'Detailed Memory Information' for every process. Regard From: Development on behalf of Simon Hausmann Sent: Wednesday, June 26, 2019 13:47 To: Michal Klocek; development@qt-project.org Subject: Re: [Development] Assistant WebKit/WebEngine support Hi, From my earlier email: " I measured on Windows with a Qt Creator built with WebEngine support and surfed a little through the docs. The memory consumption of the web engine process weighed in between 14-20 MB of RAM." That number came from the task manager in Windows. Simon From: Development on behalf of Michal Klocek Sent: Wednesday, June 26, 2019 13:31 To: development@qt-project.org Subject: Re: [Development] Assistant WebKit/WebEngine support Could you explain how did you measure web engine memory consumption to get 14-20MB of ram ? On 6/26/19 1:12 PM, Simon Hausmann wrote: > > Am 25.06.19 um 23:53 schrieb Konrad Rosenbaum: >> 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) > > > I'd really like to eliminate this myth of a "horrible memory footprint". > I sent an email earlier in this thread regarding this and presented > numbers that suggest otherwise for documentation content. > > > > Simon > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
Hi, >From my earlier email: " I measured on Windows with a Qt Creator built with WebEngine support and surfed a little through the docs. The memory consumption of the web engine process weighed in between 14-20 MB of RAM." That number came from the task manager in Windows. Simon From: Development on behalf of Michal Klocek Sent: Wednesday, June 26, 2019 13:31 To: development@qt-project.org Subject: Re: [Development] Assistant WebKit/WebEngine support Could you explain how did you measure web engine memory consumption to get 14-20MB of ram ? On 6/26/19 1:12 PM, Simon Hausmann wrote: > > Am 25.06.19 um 23:53 schrieb Konrad Rosenbaum: >> 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) > > > I'd really like to eliminate this myth of a "horrible memory footprint". > I sent an email earlier in this thread regarding this and presented > numbers that suggest otherwise for documentation content. > > > > Simon > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On Wed, 26 Jun 2019 11:24:30 + Riitta-Leena Miettinen wrote: > 3. Should the same style be used online and offline? > > For 3), we always answered „yes“, because we felt that the use cases for > reading documentation on the web or using it within Qt Creator next to the > Code editor were different. Just for clarification: I assume you meant "no" here? Christian ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
Could you explain how did you measure web engine memory consumption to get 14-20MB of ram ? On 6/26/19 1:12 PM, Simon Hausmann wrote: > > Am 25.06.19 um 23:53 schrieb Konrad Rosenbaum: >> 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) > > > I'd really like to eliminate this myth of a "horrible memory footprint". > I sent an email earlier in this thread regarding this and presented > numbers that suggest otherwise for documentation content. > > > > Simon > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
Hello all, I think this thread is mixing at least three separate, if related issues: 1. What should be used for the help back end in Qt tools (Qt Creator and Qt Assistant)? 2. What should the documentation style look like? 3. Should the same style be used online and offline? For 1), I would like to thank Konrad for the extensive list of options we have there. It would be good to put it in a JIRA task, so that it won’t get lost. We already have a task about looking into one of the options here: https://bugreports.qt.io/browse/QTBUG-74796 For 2), the doc team does not usually decide how the documentation style looks and that might be a good thing, because everybody has an opinion and they are all right, because it is an opinion 😊. The style usually comes from a designer and we implement it as well as the HTML generated by QDoc lets us. We‘ve had lot of technical problems caused by the HTML generator that are stopping us from being flashy and modern, even though of course we’d like to. For 3), we always answered „yes“, because we felt that the use cases for reading documentation on the web or using it within Qt Creator next to the Code editor were different. In the latter case, the white space was minimized, system font was used, and the text size was smaller to save space. Because QDoc separates Content from formatting, it is easily possible to generate documentation for different purposes from the same source if all the authors use QDoc commands consistently. The helps still looked nice, even they were different from the online version, until we had to start depending on QTextBrowser. Thanks for the bug reports! To save everyone some time, please look around in JIRA for existing bugs first and report all style-related issues as QTBUGS. The styles come from Qt and only issues in the content of the Qt Creator Manual should be reported as a QTCREATORBUG. This is because the fixes will be done in Qt, not Qt Creator. I moved one of them here and reopened it, because after more study it looks like it might have been cause by a CSS change: https://bugreports.qt.io/browse/QTBUG-76705 So, when you report bugs, the more information you can include about what is wrong and when it changed, the more chance you’ll probably have of getting the bug fixed. Cheers, Leena Date: Wed, 26 Jun 2019 10:09:24 + From: "Palaraja, Kavindra" To: "development@qt-project.org" Subject: Re: [Development] Assistant WebKit/WebEngine support Message-ID: <557ee263-e641-464f-b3b2-ac212c749...@luxoft.com> Content-Type: text/plain; charset="utf-8" Wow, I had no idea in my 12 years of being a Technical Writer that it's possible to annoy so many developers just by discussing a possibility of having better looking, higher quality documentation :) On the other hand, as a former Troll who wrote the first version of Creator's manual (back when it was called Greenhouse) I'm actually slightly honored because so many developers are still so attached to how Qt's documentation looks in Creator. Firstly -- the documentation isn't only used by you (anyone reading this e-mail). There are other people who use it too, like Designers or Technical Writers. A Designer would cringe at this content and we would lose them as a possible customer. There are also Managers and Architects who look at documentation to decide if they want to buy a Qt license. Every day, a Technical Writer has two options -- fix content or fix the content experience. It's a daily battle. And if your team doesn't have a Content Strategist, an Information Architect, or a Site Designer, then these criteria are things that the Writer has to consider. So every time your Technical Writer spends time fighting to shrink an image, or find out why something doesn't render as expected, you're wasting their time. You might as well let the Technical Writer spend time on the content. That's the key -- as many of you have said -- you want to have the content there. OK, you don't care how it looks -- I get it. But I care, as do many other people who may not be on this list, because it makes my content look bad. If the content looks better, you can write less. Imagine getting less walls of text to read. Maybe like Visual Studio Code's Release Notes -- there are GIFs here that show you the steps of how to use a feature, instead of writing those lines of "Select X, choose Y, Click Z." https://code.visualstudio.com/updates/v1_35 -- They actually display this content in their IDE as well. Seeing is believing. I apologize for not putting in a screenshot earlier. Here you go, here's the ugly table. vs. https://doc-snapshots.qt.io/qtapplicationmanager/manifest.html#<https://doc-snapshots.qt.io/qtapplicationmanager/manifest.html> Here's the diagram that can't be scaled without ruining it's clarity. Ye
Re: [Development] Assistant WebKit/WebEngine support
Am 25.06.19 um 23:53 schrieb Konrad Rosenbaum: > 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) I'd really like to eliminate this myth of a "horrible memory footprint". I sent an email earlier in this thread regarding this and presented numbers that suggest otherwise for documentation content. Simon ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
26.06.2019, 02:57, "Bastiaan Veelo" : > On 26/06/2019 00:15, Jean-Michaël Celerier wrote: >> 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 > That's QWebView based (WebKit) pre Qt 5.6. Back then Assistant was great as > well. It uses QtWebKit 5.212, not ancient version from Qt 5.5 -- Regards, Konstantin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On 6/26/19 10:09 AM, Eike Ziller wrote: >> On 25. Jun 2019, at 23:53, Konrad Rosenbaum wrote: >> >> Hi, >> >> On 6/25/19 9:59 PM, Tor Arne Vestbø wrote: >>> On 25 Jun 2019, at 21:30, Konrad Rosenbaum 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. That's fine for my *personal* use cases with Qt Creator and using help in there. While it would be desirable to have the same look and feel as on https://doc.qt.io/, I never had a problem with that. If I'm using help mode, I'm looking for a particular information and the styling never got in my way. So that's 95% fine with me. But we are having this discussion/thread here, so we can rule this out, except for a fallback of course. >> 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 > > And we really miss a good, small HTML+CSS viewer for Qt. Currently we offer > either crap (QTextBrowser, sorry for the harsh words), or something huge, > that does too much, and is more difficult to deploy (QtWebEngine). > QtWebKit was an bearable compromise at the time, it didn’t hurt so much as > QtWebEngine. > > Option 2 1/2: Leave QTextBrowser alone but create a lightweight HTML+CSS > viewer, possibly based on something like https://github.com/litehtml/ . > Pros: documentation becomes visually more pleasing; dependencies really only > contain what is needed for HTML+CSS; a solution benefits other developers > using Qt > Con: someone actually has to put in the work +1 for this one, option 2, or a *heavily* reduced/stripped webengine, depending on the amount of estimated work. Estimating this is also 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 > > I agree with Thiago that this also requires WebKit to be updated with > security fixes. It will potentially show downloaded content from anywhere, > and it’s not nice if someone can offer a malicious qch, using known security > issues in WebKit. And with JavaScript etcetera the “attack area” is much > larger than actually necessary for browsing documentation. > >> 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) > > What is the state of Linux distributions and QtWebEngine? > I remember that there were some concerns, but neither remember details, nor > how it went on. > Technically the QTextBrowser backend would still be available as a fallback, > but that doesn’t help if the documentation starts to use features/CSS that is > not supported by it. > >> 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 > > We also either need to be able to register a scheme handler for qthelp, or > use a local server for the help. > Also, WebView can use the “platform” API, but on Linux there is none. So we > need an implementation on Linux based on one of the other options in any case. > >> Option 6: use plain platform browser to show local files >> Pros: minimal footprint; assistant can be retired; guaranteed good rendering >
Re: [Development] Assistant WebKit/WebEngine support
26.06.2019, 11:13, "Eike Ziller" : > I agree with Thiago that this also requires WebKit to be updated with > security fixes. It will potentially show downloaded content from anywhere, > and it’s not nice if someone can offer a malicious qch, using known security > issues in WebKit. And with JavaScript etcetera the “attack area” is much > larger than actually necessary for browsing documentation. Note that it's possible to disable JavaScript completely at run time, reducing attack surface. > We also either need to be able to register a scheme handler for qthelp, or > use a local server for the help. > Also, WebView can use the “platform” API, but on Linux there is none. So we > need an implementation on Linux based on one of the other options in any case. As well as implementation for Windows. -- Regards, Konstantin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
I think the option 2 (enhancements in QTextBrowser) is the best one, since the time investment spent on it will benefit for all users of QTextBrowser, not only those using Qt help system. So big +1 here! However, if we go with the webengine (or webkit) way, I would be very happy that the existing solution (crappy QTextBrowser) is still there as a fallback, even if the content may start to look even more ugly (due to potential "style" redesign of qch files, which most probably will happen when we have full functional web browser in). I remember the old days, when we had mandatory webkit: I never compiled it, since it was a big pain (many external dependencies, many times it just didn't compile, very long time spent on compilation). Usually the result was that after half a day spent on preparation / compilation, I saw not working help. So I had to use online docs in my browser. Another option which comes to my mind is: Option 8: Make the webengine project configurable / customizable enough, so that we may cut off all networking and stuff we don't need, keeping only the pure HTML rendering. This would be also benefit for others - maybe then much more people would start using it. I realize that this would probably be a huge refactoring and a long term solution. However, maybe it's worth to think about it now, before Qt6... Jarek ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
Hey Andre, ... .. I find it somewhat strange that a party that ships a custom Creator built anyway pushes so hard on a solution that is harmful for some instead of simply building their help plugin in their favourite configuration. Andre' Ah, yet another social stab instead of a technical discussion. It hurts man, it hurts. I'm not sure whom you mean here. It can't be my employer as The Qt Automotive Suite is shipped by The Qt Company. Regarding the push for a solution, my employer isn't pushing for it. I've been asked to adapt it to the current QTextBrowser beauty. But I can't because QTextBrowser doesn't support the official qdoc stylesheet. So I'm trying to ask for a better solution. Because I've seen better and very few things make me happier than walking around an office where developers use Qt Creator. 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
Re: [Development] Assistant WebKit/WebEngine support
> On 25. Jun 2019, at 23:53, Konrad Rosenbaum wrote: > > Hi, > > On 6/25/19 9:59 PM, Tor Arne Vestbø wrote: >> On 25 Jun 2019, at 21:30, Konrad Rosenbaum 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 And we really miss a good, small HTML+CSS viewer for Qt. Currently we offer either crap (QTextBrowser, sorry for the harsh words), or something huge, that does too much, and is more difficult to deploy (QtWebEngine). QtWebKit was an bearable compromise at the time, it didn’t hurt so much as QtWebEngine. Option 2 1/2: Leave QTextBrowser alone but create a lightweight HTML+CSS viewer, possibly based on something like https://github.com/litehtml/ . Pros: documentation becomes visually more pleasing; dependencies really only contain what is needed for HTML+CSS; a solution benefits other developers using Qt 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 I agree with Thiago that this also requires WebKit to be updated with security fixes. It will potentially show downloaded content from anywhere, and it’s not nice if someone can offer a malicious qch, using known security issues in WebKit. And with JavaScript etcetera the “attack area” is much larger than actually necessary for browsing documentation. > 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) What is the state of Linux distributions and QtWebEngine? I remember that there were some concerns, but neither remember details, nor how it went on. Technically the QTextBrowser backend would still be available as a fallback, but that doesn’t help if the documentation starts to use features/CSS that is not supported by it. > 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 We also either need to be able to register a scheme handler for qthelp, or use a local server for the help. Also, WebView can use the “platform” API, but on Linux there is none. So we need an implementation on Linux based on one of the other options in any case. > 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) Also I see u
Re: [Development] Assistant WebKit/WebEngine support
On Tuesday, 25 June 2019 18:08:28 PDT Thiago Macieira wrote: > > Are you worried about the lack of security patches? I can see how that > > matters for an ordinary browser implemented with Qt, but for Assistant > > and Creator that exclusively display locally installed generated > > compressed help files, security concerns are a lot lower. > > Sure, but the fact that Qt Creator is using it could lead people to trying > for a web browser. > > Not to mention that even if Qt's help documents are safe, other documents > you may want to view may not be so. Actually, let me be even more clear: shipping software with known security issues that have been fixed elsewhere is unacceptable. Please don't try to say "but this code isn't used in this application", it's very hard to prove that and obtain security exceptions in many companies. At Intel, we simply can't. If Qt Creator begins depending on a version of a web engine that has open security issues whose fixes are available but not applied, we cannot ship it in our Linux distribution (Clear Linux). Other Linux distributions may have similar policies. If the affected code isn't exercised, please prove so by removing the code from the build. This is usually more effort than applying the fix. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On Tuesday, 25 June 2019 17:07:20 PDT Bastiaan Veelo wrote: > > at this point, what's speaking againt qtwebkit is its track record of > > release. Until it starts making regular releases again, I can't recommend > > it. And Qt Creator (or any other application) shouldn't begin using it > > again until those regular releases resume. > > Are you worried about the lack of security patches? I can see how that > matters for an ordinary browser implemented with Qt, but for Assistant > and Creator that exclusively display locally installed generated > compressed help files, security concerns are a lot lower. Sure, but the fact that Qt Creator is using it could lead people to trying for a web browser. Not to mention that even if Qt's help documents are safe, other documents you may want to view may not be so. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On 25/06/2019 18:16, Thiago Macieira wrote: On Tuesday, 25 June 2019 09:05:21 PDT Konstantin Tokarev wrote: It hasn't been updated in years. Don't use it, since it's clearly not getting security updates. New version is currently in development, and should be ready in time frame of Qt 5.14 (at least functionality required for displaying help) 5.212 branch should be fine for use with local help files, e.g. you can take fresh\ from http://download.qt.io/snapshots/ci/qtwebkit/5.212/1560153112/ Konstantin, at this point, what's speaking againt qtwebkit is its track record of release. Until it starts making regular releases again, I can't recommend it. And Qt Creator (or any other application) shouldn't begin using it again until those regular releases resume. Are you worried about the lack of security patches? I can see how that matters for an ordinary browser implemented with Qt, but for Assistant and Creator that exclusively display locally installed generated compressed help files, security concerns are a lot lower. Bastiaan. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On 26/06/2019 00:15, Jean-Michaël Celerier wrote: 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 That's QWebView based (WebKit) pre Qt 5.6. Back then Assistant was great as well. Bastiaan. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
> 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 wrote: > Hi, > > On 6/25/19 9:59 PM, Tor Arne Vestbø wrote: > > On 25 Jun 2019, at 21:30, Konrad Rosenbaum 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@qt-project.org > https://lists.qt-project.org/listinfo/development > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
Hi, On 6/25/19 9:59 PM, Tor Arne Vestbø wrote: > On 25 Jun 2019, at 21:30, Konrad Rosenbaum 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 pEpkey.asc Description: application/pgp-keys ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
Il 25/06/19 16:30, Palaraja, Kavindra ha scritto: The idea is to have parity in the sense of 1:1 appearance of how the documentation looks like. Here's a ticket that hasn't gone very far: https://bugreports.qt.io/browse/QTCREATORBUG-15887 Can we keep the personal attacks out of this and perhaps stick to the issue? I'm definitely not lying. I don't see any tables being rendered the way tables should be rendered in HTML. Unless I'm losing my eyesight? You could check:https://doc.qt.io/QtApplicationManager/manifest.html none of that alternating row color or design shows up. As a Technical Writer, I expect the output to look like that. So why doesn't it? I'm not attached to WebEngine, I just want to get the expected output. Because the Qt text document classes (*) don't support that kind of styling: https://doc.qt.io/qt-5/richtext-html-subset.html They *do* support tables, and I'll grant, they look horrible. And they do support background colours for table cells, meaning that a table with alternating row colours could in principle be produced, albeit not by using fancy CSS nth-odd/even selectors. (By the way, I have no idea how the Assistant docs are currently generated and styled.) Anyhow, let me raise some further questions: * Is the whole idea of moving to a web browser driven exclusively by these missing features in terms of styling / HTML / JS support, that prevent more unification between content offered on the web vs. the one integrated in QtHelp? ** Have such missing features been identified, in the first place? At least the ones we care about w.r.t. Qt's own help. ** Have feature requests been filed against QTextDocument? Have their costs then been estimated? (Again, in the principle of EYODF) ** Have workarounds been discussed? ** Was it simply deemed not worth doing such work when we have another working solution, "easy" to reach, and that will survive any redesign/restyling of the docs that is going to happen every now and then? * Is the whole idea part of a bigger plan of further improving QtHelp, e.g. make it possible to load external resources through it such as videos, community forums, PDFs, you name it? Basically, out of reach for any effort at possibly improving QTD. The thing is, the arguments _against_ this move are many. If you combine them with the ordinary human behaviour where "fear of change" trumps "perceived benefits" every single time, you'll get a very agitated audience. (*) you're officially a Qt old-school if you remember the codename for them. -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On 25/06/2019 21:30, Konrad Rosenbaum wrote: It is documentation for developers for crying out loud! No it is not. Assistant is distributed as a help viewer, to be distributed along with applications for use by the customers of your customers. As soon as QTextBrowser in its current sorry state of rendering HTML became the sole supported browser, it completely FAILED that purpose. Not just "a little bit more Spartan but we can live with it", no, it leaves out *critical* information! It is completely undistributable in our case. Firstly the fonts are a complete mess, with different elements having unrelated sizes, weights and types. If you zoom, only the headings zoom! We use styled to accomplish frames around labels to refer to elements in screen shots[1] that vanish in QTextBrowser. We use CSS styled tables to render hyperlinked menus that occur in the user interface, and the borders should be there because they are there in the UI; they are not in QTextBrowser. We have hundreds of these menus in multiple translations, and screen shots are just not going to work in a 400-page manual. Try keeping those up to date. And what about those hyperlinks? Don't you dare suggest those HTML 1.0 tables. We use CSS styles description links to highlight call-outs[2]. They don't work in QTextBrowser. Deciding that it was okay to drop Qt WebKit in Qt Assistant because with some tweaking of your content the Qt documentation for Qt developers could be made kind of acceptable to some people was a complete let down and Qt's biggest mistake so far. Pardon my lingo. Bastiaan. [1] https://www.sarc.nl/images/manuals/pias/htmlEN/loading_module_gui.html#loading_gui_layout [2] https://www.sarc.nl/images/manuals/pias/htmlEN/fwy_export.html ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
> On 25 Jun 2019, at 22:53, André Pönitz wrote: > > On Tue, Jun 25, 2019 at 07:59:16PM +, Tor Arne Vestbø wrote: >>> On 25 Jun 2019, at 21:30, Konrad Rosenbaum 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. > > I find it actually quite helpful and to the point. Huh? You find straw-men helpful and to the point? > >>> As a developer I expect it to frigging be there, no matter the look. That's >>> it. >> >> As a developer I expect documenation on par with other projects we like to >> compare ourselves with, both in terms of features/usability and visual >> asthetics. > > So we have different kinds of developers, and that's fine and expected. Exactly my point. I wanted to add another data point. Tor Arne ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On Tue, Jun 25, 2019 at 07:59:16PM +, Tor Arne Vestbø wrote:
> > On 25 Jun 2019, at 21:30, Konrad Rosenbaum 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.
I find it actually quite helpful and to the point.
> > As a developer I expect it to frigging be there, no matter the look. That's
> > it.
>
> As a developer I expect documenation on par with other projects we like to
> compare ourselves with, both in terms of features/usability and visual
> asthetics.
So we have different kinds of developers, and that's fine and expected.
Also, different people have different ideas on what is usable, or
aethetic. E.g. the animations build into doc.qt.io are quite the opposite
of what I consider usable or even aesthetic. Already the idea to have
animated help in Creator makes me cringe.
The discussed idea to make the WebEngine dependency mandatory would
effectively mean that some people will not be able to use the help plugin
at all anymore, and for me personally that I will stop building and
consequently occasionally using ("testing") it. That's definitely an
disadvantage for me, which I dislike.
Creator so far tried to be usable for a large audience, and even if clearly
not perfect I think we are on track there. The problem is there's no
obvious "one size fits all", especially when it comes to aestetics. The
current state of the code base allows in principle "full webbrowser for
beefy machines" usecase as well as getting most of the functionality in
restricted setups, and I find it somewhat strange that a party that
ships a custom Creator built anyway pushes so hard on a solution that
is harmful for some instead of simply building their help plugin in
their favourite configuration.
Andre'
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
> On 25 Jun 2019, at 21:30, Konrad Rosenbaum 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. > As a developer I expect it to frigging be there, no matter the look. That's > it. As a developer I expect documenation on par with other projects we like to compare ourselves with, both in terms of features/usability and visual asthetics. Tor Arne ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On 21/06/2019 11:08, Bastiaan Veelo wrote: [...] The best solution would therefore be, in my opinion, to change the order of compilation, apply the existing patch, and consider refactorings and unifications thereafter. I went ahead and did this. https://github.com/veelo/qttools is a fork of qttools for the sole purpose of compiling Qt Assistant against a stock binary distribution of Qt as an independent application. It compiles quickly and conveniently using Qt Creator. The 5.13_assistant_webengine branch contains the WebEngine support by Allan Sandfeld Jensen and several additional fixes of my own. At least I have a working solution without the need to wait until the next morning for compilation of Qt and WebEngine to complete, with reasonable odds of being able to keep in sync with upstream and future releases. Bastiaan. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
25.06.2019, 22:32, "Bastiaan Veelo" : > On 21/05/2019 14:50, Konstantin Tokarev wrote: >> 21.05.2019, 15:47, "Bastiaan Veelo" : >>> On 20/05/2019 19:02, Konstantin Tokarev wrote: [...] Current version of QtWebKit from 5.212 works on Windows, there are binaries at http://download.qt.io/snapshots/ci/qtwebkit/5.212/latest/qtwebkit/ >>> Extracted into qtbase and Assistant builds like a charm! However running >>> it gives >>> >>> "The procedure entry point >>> ?staticMetaObject@QSslSocket@@2UQMetaObject@@B could not be located in >>> the dynamic link library D:\Qt\gerrit\qt5\qtbase\bin\Qt5WeKit.dll". >>> >>> I have checked out the Qt dev branch from May 11, which I can imagine >>> could cause problems. Do you happen to know which Qt version those >>> QtWebKit binaries are known to work with? >> 5.10 > > I decided not to compile Qt myself any more, because I can't wait until > the next day for it to finish each time. Therefore I have forked qttools > and am compiling Assistant separately using a stock binary Qt > distribution. For some reason though, 5.10 is completely absent from the > installer. I'll have to let the WebKit approach rest for the time being. You can use these binaries with Qt 5.12: http://download.qt.io/snapshots/ci/qtwebkit/5.212/1560153112/qtwebkit/ -- Regards, Konstantin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
Hi,
...my 2 cents or so...
On 6/25/19 4:30 PM, Palaraja, Kavindra wrote:
> No, parity isn't Google's search box. There's already a search feature in
> Creator.
>
> No, not "The Qt Company is hiring" either.
>
> The idea is to have parity in the sense of 1:1 appearance of how the
> documentation looks like.
Pardon my lingo, but I do not give a rats furry behind about how it
looks and whether it is on full parity with the way it is shown in a
browser as long as I have all the content.
It is documentation for developers for crying out loud! Its purpose is
not to win any design prices, but to educate the developers.
> Here's a ticket that hasn't gone very far:
>
> https://bugreports.qt.io/browse/QTCREATORBUG-15887
>
> Can we keep the personal attacks out of this and perhaps stick to the issue?
> I'm definitely not lying. I don't see any tables being rendered the way
> tables should be rendered in HTML. Unless I'm losing my eyesight?
Sorry, but I just tried a very simple example with QTextBrowser:
In my book this is exactly like a table should be rendered. Granted it
is not very flashy looking, but it is definitely a table and it has borders.
Source:
#include
#include
int main(int ac,char**av)
{
QApplication a(ac,av);
QTextBrowser tb;
tb.setHtml("helloworldwoohoo!");
tb.show();
return a.exec();
}
(embedding
Re: [Development] Assistant WebKit/WebEngine support
On 21/05/2019 14:50, Konstantin Tokarev wrote: 21.05.2019, 15:47, "Bastiaan Veelo" : On 20/05/2019 19:02, Konstantin Tokarev wrote: [...] Current version of QtWebKit from 5.212 works on Windows, there are binaries at http://download.qt.io/snapshots/ci/qtwebkit/5.212/latest/qtwebkit/ Extracted into qtbase and Assistant builds like a charm! However running it gives "The procedure entry point ?staticMetaObject@QSslSocket@@2UQMetaObject@@B could not be located in the dynamic link library D:\Qt\gerrit\qt5\qtbase\bin\Qt5WeKit.dll". I have checked out the Qt dev branch from May 11, which I can imagine could cause problems. Do you happen to know which Qt version those QtWebKit binaries are known to work with? 5.10 I decided not to compile Qt myself any more, because I can't wait until the next day for it to finish each time. Therefore I have forked qttools and am compiling Assistant separately using a stock binary Qt distribution. For some reason though, 5.10 is completely absent from the installer. I'll have to let the WebKit approach rest for the time being. Bastiaan. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On Tue, Jun 25, 2019 at 10:52:29AM +0300, Konstantin Tokarev wrote:
> > It worked up to a certain degree nicely in the build system by
> > de-selecting options, than quite a bit more by actually removing code.
> > Getting rid of all of JS was not obviously possible.
>
> Removing code makes result unmaintainable,
Sure, that's understood. I wanted to get a gut feeling on how
much gain will there for how much gain.
> while minimal configuration with existing options makes a good
> balance IMO.
That's probably easiest, but leaves e.g. the whole JS machinery intact
which I do not really want to have for a QTextBrowser-with-table-borders
replacement.
Of course, the situation is in no way worse than what WebEngine would
provide.
> > The result was ok-ish size-wise (and for me definitely preferable over
> > WebEngine) but the question is where to put to cut. In some setups
> > ("Want to see DevDays videos") even cutting multimedia plugins won't be
> > accepted by everyone. I.e. the "need" for a "full browser" is likely
> > to always exist, and that's currently served by "use external help".
>
> We have MediaFoundation player on Windows these days so it can work
> without pulling in Qt Multimedia
> and uses system-provided codecs, so
> enabling multimedia won't add that much. However, for multimedia content
> there is always an option to add external link, as this is not the kind of
> documentation you really need to have inside your IDE or in similar context.
Definitely not. But it's a point that some people tend to cite as
an "advantage", nightmare or not...
Andre'
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On Tuesday, 25 June 2019 09:05:21 PDT Konstantin Tokarev wrote: > > It hasn't been updated in years. Don't use it, since it's clearly not > > getting security updates. > > New version is currently in development, and should be ready in time frame > of Qt 5.14 (at least functionality required for displaying help) > > 5.212 branch should be fine for use with local help files, e.g. you can take > fresh\ from http://download.qt.io/snapshots/ci/qtwebkit/5.212/1560153112/ Konstantin, at this point, what's speaking againt qtwebkit is its track record of release. Until it starts making regular releases again, I can't recommend it. And Qt Creator (or any other application) shouldn't begin using it again until those regular releases resume. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
25.06.2019, 19:01, "Thiago Macieira" : > On Tuesday, 25 June 2019 06:43:06 PDT Eike Ziller wrote: >> What is the state of QtWebKit(2) > > It hasn't been updated in years. Don't use it, since it's clearly not getting > security updates. New version is currently in development, and should be ready in time frame of Qt 5.14 (at least functionality required for displaying help) 5.212 branch should be fine for use with local help files, e.g. you can take fresh\ from http://download.qt.io/snapshots/ci/qtwebkit/5.212/1560153112/ -- Regards, Konstantin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On Tuesday, 25 June 2019 06:43:06 PDT Eike Ziller wrote: > What is the state of QtWebKit(2) It hasn't been updated in years. Don't use it, since it's clearly not getting security updates. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
No, parity isn't Google's search box. There's already a search feature in Creator. No, not "The Qt Company is hiring" either. The idea is to have parity in the sense of 1:1 appearance of how the documentation looks like. Here's a ticket that hasn't gone very far: https://bugreports.qt.io/browse/QTCREATORBUG-15887 Can we keep the personal attacks out of this and perhaps stick to the issue? I'm definitely not lying. I don't see any tables being rendered the way tables should be rendered in HTML. Unless I'm losing my eyesight? You could check: https://doc.qt.io/QtApplicationManager/manifest.html none of that alternating row color or design shows up. As a Technical Writer, I expect the output to look like that. So why doesn't it? I'm not attached to WebEngine, I just want to get the expected output. Kavindra. On 25.06.19, 16:12, "Development on behalf of Giuseppe D'Angelo via Development" wrote: Hi, Il 25/06/19 14:28, Palaraja, Kavindra ha scritto: > > Hi Kirill, > > I can’t speak for the size of WebEngine or the complexity of this > solution, but I can speak for the look & feel of the documentation. > > The current situation with Qt Creator’s documentation is not about how > wonderful the content would look like. It’s about the basics of what > developers expect to get when they look at the documentation. It’s to > match what we have on https://doc.qt.io in the first place. I’m talking > about _/parity/_. I’m not asking for some crazy animation – just a 1:1 > with the official Qt documentation that’s published online. Sorry, but now I have to play devil's advocate: Does that parity include things like Google search integration, or the current ads like "The Qt Company is hiring", not and so on? The moment you start customizing things > > * We can’t display a real code blocks in Creator – you don’t get that > black box with syntax highlighted code snippets in Creator. When you > document this, you use \code, \endcode, or \badcode in qdoc. None of > this is actually being displayed as expected in Creator. Is this a limitation of QTextBrowser or is the style applied for the docs there stripping out code highlighting? I know for a fact that works in QTextBrowser. > If source code was not behaving as expected when compiled, you’d > consider it a bug right? So why is this different because it’s > documentation? Because it’s less important? > > * We can’t display a proper table with the borders in Creator – try it > out, search for QObject, look at the API reference, there’s actually > no table there. Just some indentation with white background. Now > compare it to this: https://doc.qt.io/qt-5/qobject.html Are you referring to the 1px table wrapping the list of members, etc.? Saying that we want to move to a full blown browser for that makes me think that this is a case of Qt not eating its own dogfood. Is it impossible to fix QTextDocument to support them properly? > You say: > > “Nowadays help/doc search activities is much more than just open offline > page with descriptions of classes and methods with examples.” > > Exactly. I’d like to have more than this – but we don’t even have basic > HTML. Remember, a table doesn’t render at all. It’s not possible with > regular Creator docs. It’s possible to have better documentation, but we > need something more than just QTextBrowser. "A table does not render at all" is a lie. Cheers, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts 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
Re: [Development] Assistant WebKit/WebEngine support
Am 25.06.2019 um 16:11 hat Giuseppe D'Angelo via Development geschrieben: Saying that we want to move to a full blown browser for that makes me think that this is a case of Qt not eating its own dogfood. Is it impossible to fix QTextDocument to support them properly? https://codereview.qt-project.org/c/qt/qtbase/+/126950 could be a start. Still needs some work though. Nils signature.asc Description: PGP signature ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
Hi, Il 25/06/19 14:28, Palaraja, Kavindra ha scritto: Hi Kirill, I can’t speak for the size of WebEngine or the complexity of this solution, but I can speak for the look & feel of the documentation. The current situation with Qt Creator’s documentation is not about how wonderful the content would look like. It’s about the basics of what developers expect to get when they look at the documentation. It’s to match what we have on https://doc.qt.io in the first place. I’m talking about _/parity/_. I’m not asking for some crazy animation – just a 1:1 with the official Qt documentation that’s published online. Sorry, but now I have to play devil's advocate: Does that parity include things like Google search integration, or the current ads like "The Qt Company is hiring", not and so on? The moment you start customizing things * We can’t display a real code blocks in Creator – you don’t get that black box with syntax highlighted code snippets in Creator. When you document this, you use \code, \endcode, or \badcode in qdoc. None of this is actually being displayed as expected in Creator. Is this a limitation of QTextBrowser or is the style applied for the docs there stripping out code highlighting? I know for a fact that works in QTextBrowser. If source code was not behaving as expected when compiled, you’d consider it a bug right? So why is this different because it’s documentation? Because it’s less important? * We can’t display a proper table with the borders in Creator – try it out, search for QObject, look at the API reference, there’s actually no table there. Just some indentation with white background. Now compare it to this: https://doc.qt.io/qt-5/qobject.html Are you referring to the 1px table wrapping the list of members, etc.? Saying that we want to move to a full blown browser for that makes me think that this is a case of Qt not eating its own dogfood. Is it impossible to fix QTextDocument to support them properly? You say: “Nowadays help/doc search activities is much more than just open offline page with descriptions of classes and methods with examples.” Exactly. I’d like to have more than this – but we don’t even have basic HTML. Remember, a table doesn’t render at all. It’s not possible with regular Creator docs. It’s possible to have better documentation, but we need something more than just QTextBrowser. "A table does not render at all" is a lie. Cheers, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
> On Jun 24, 2019, at 22:44, Lars Knoll wrote: > > >> On 24 Jun 2019, at 21:54, Tor Arne Vestbø wrote: >> >> >> >>> On 24 Jun 2019, at 14:43, Simon Hausmann wrote: >>> >>> I have two more numbers to add: Compressed (7z) the download size would >>> be around ~44 MB. I measured on Windows with a Qt Creator built with >>> WebEngine support and surfed a little through the docs. The memory >>> consumption of the web engine process weighed in between 14-20 MB of RAM. >>> >>> So it looks like this AFAICS: >>> >>> * We would be adding 145 MB of additional disk usage >>> >>> * We would add ~44 MB to the download size of Qt Creator >>> >>> * We would eat ~14-20 MB of additional RAM (not quite fair though, >>> as we'd have to subtract the QTextDocument memory usage for a diff). >>> >>> >>> I don't quite share the opinion that these are "beastly" numbers for >>> desktop machines running C++ development environments. I think that they >>> are worth it. In exchange we can show external content like cppreference >>> or cmake docs without having to worry about their rendering, we can get >>> rid of our separate style sheets and workarounds and we can render the >>> Qt documentation the same way as on the website. We can eliminate an >>> entire class of problems, and we can still prevent such content from >>> accessing remote websites. >>> >>> >>> We've had this situation for a long time now and I think that we should >>> finally move forward and give our users better quality at the expense of >>> their disk space, memory consumption and download size. >>> >> >> I fully agree with this. Thanks for the numbers Simon! > > Another +1 from me. Let’s stop fighting this. We need something that can > properly display any HTML content (and maybe PDF and things as well) that we > throw at it. PDFs (and things) can be opened in external applications which then can provide whatever other related features the user might want. We really need something that can properly render HTML + CSS + images. > Not having a fully working engine will always lead to issues where this > causes lots of additional work in other places, e.g. for the documentation > team that has to tweak the content of our qch files. Currently our inline > docs in Creator look a lot worse than the web version and lack many features > that we have on the web based docs. How come we accept that? Using QtWebEngine for that means that 30-40% of Qt Creator is just for viewing help. And 70% or so of that actually would actually not be required for rendering beautiful help pages like in a browser (QtWebKit was ~40 MB back in the days, and was technically already more than needed). > We do want integrated help and we want it to look good. That means we have to > simply accept the fact that we’ll need an integrated browser. What is the state of QtWebKit(2) ? Do we have that on CI ? Can we have an export? > Cheers, > Lars -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.zil...@qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
> On Jun 25, 2019, at 10:26, Simon Hausmann wrote: > > > Am 25.06.19 um 10:10 schrieb Morten Sørvig: >> I’m not sure if it has been mentioned; we have another option which is to >> use the OS web browser component via the Qt WebView module. >> >> The benefits would be >> >> * up-to-date web browser (and someone else keeps it up to date for us) >> * insignificant additional download size >> * no trouble with restricted platforms where shipping a full web browser is >> not feasible (but then maybe creator isn’t going to run on those platforms, >> anyway) >> >> QWebView’s platform coverage may be insufficient for Creator, which means >> >> * no html docs on those platforms :( >> * or, we expand QWebView platform coverage >> * or, QT WebView does have a WebEngine backend > > > I think that would indeed be desirable in the long run. At the moment > this is limited to macOS (and from the looks of it, Qt Creator has > direct support for using WebKit on macOS, but oddly my build doesn't > have it enabled?). It is there, but not used by default. You can switch between different backends (that are supported in your build) with e.g. QTC_HELPVIEWER_BACKEND=native (for the native webview backend) or =textbrowser for the QTextBrowser fallback. It has issues though. Which is why it is not default. Embedding the native view into Qt Creator so far didn’t work reliably, with different issues depending on Qt version. The collection of issues I had so far, never all together though ;) - blank webview - working webview but blank QML views (possibly fighting over OpenGL contexts?) - mouse hover not working - last time I checked the webview was scaled x2 when it first opened > I'm quite excited about Microsoft's WebView2 > development that could become a very nice backend for QWebView on > Windows. I played with it the other day and it looks quite nice. The > deployment model is not suitable for us at the moment (nuget only) and > it's still in an early release phase. However it comes with a powerful > API and an opt-in evergreen distribution model. > > QWebView would also need to be improved to support feeding custom data > into it, unless somebody implements serving via a local http server. > > > I think these are all options in the future. > > > Simon > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.zil...@qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
… I don't think that a lot of developers really care about how wonderful help module looks like as long as it answers development related questions clearly and precisely. Nowadays help/doc search activities is much more than just open offline page with descriptions of classes and methods with examples. We search through QA web sites and dev forums, tutorials and videos, source repositories, social discussion platform. Why not to delegate all those activities to proper browser environment of choice with all its extensions and custom setups? And just improve query part of qtc help (index, content seaches) to speed up simple Qt and c++ related queries and fall back to proper web search engines outside of ide for anything more complex. Embedding browser into ide seems to me like a huge misdirection. Hi Kirill, I can’t speak for the size of WebEngine or the complexity of this solution, but I can speak for the look & feel of the documentation. The current situation with Qt Creator’s documentation is not about how wonderful the content would look like. It’s about the basics of what developers expect to get when they look at the documentation. It’s to match what we have on https://doc.qt.io in the first place. I’m talking about _parity_. I’m not asking for some crazy animation – just a 1:1 with the official Qt documentation that’s published online. * We can’t display a real code blocks in Creator – you don’t get that black box with syntax highlighted code snippets in Creator. When you document this, you use \code, \endcode, or \badcode in qdoc. None of this is actually being displayed as expected in Creator. If source code was not behaving as expected when compiled, you’d consider it a bug right? So why is this different because it’s documentation? Because it’s less important? * We can’t display a proper table with the borders in Creator – try it out, search for QObject, look at the API reference, there’s actually no table there. Just some indentation with white background. Now compare it to this: https://doc.qt.io/qt-5/qobject.html You say: “Nowadays help/doc search activities is much more than just open offline page with descriptions of classes and methods with examples.” Exactly. I’d like to have more than this – but we don’t even have basic HTML. Remember, a table doesn’t render at all. It’s not possible with regular Creator docs. It’s possible to have better documentation, but we need something more than just QTextBrowser. 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
Re: [Development] Assistant WebKit/WebEngine support
Hello, That for sure doesn't account for complexity of what we are getting with this move. Quite heavily stripped down version of chromium inside webengine has ~20M loc, that is 10x times more than whole qtc. The actual browser is twice as big in terms of loc. Official doc page for building Qt suggests to skip webengine. Number of supported compilers and environments is also limited. MSYS2 environment has latest mingw and clang, and this environment is sufficient to build whole Qt (and libraries are there except, of course, webengine). WebEngine doesn't only display fancy looking htmls with styles, it is almost full-blown browser. Why is it needed this way in ide? Qt Creator is not a light-weight ide already. Popularity of editors-ides like vscode, sublime, vim/emacs-based envs clearly shows how important this factor is. Will it run fine on 5-6 years old laptops or on recent phones and tables with desktop features and arm cpus? I don't think that a lot of developers really care about how wonderful help module looks like as long as it answers development related questions clearly and precisely. Nowadays help/doc search activities is much more than just open offline page with descriptions of classes and methods with examples. We search through QA web sites and dev forums, tutorials and videos, source repositories, social discussion platform. Why not to delegate all those activities to proper browser environment of choice with all its extensions and custom setups? And just improve query part of qtc help (index, content seaches) to speed up simple Qt and c++ related queries and fall back to proper web search engines outside of ide for anything more complex. Embedding browser into ide seems to me like a huge misdirection. From: Development on behalf of Simon Hausmann Sent: Monday, June 24, 2019 14:43 To: development@qt-project.org Subject: Re: [Development] Assistant WebKit/WebEngine support Am 24.06.19 um 12:31 schrieb Eike Ziller: >> * What exactly is so big about WebEngine? What is this size that many are >> hinting at but won't provide the number? > My numbers on macOS: > > WebEngineCore.framework = 145 MB > Current Qt Creator application = 430 MB (and about 60 MB of this we currently > try to get rid off again because it’s actually duplicate binary code) I have two more numbers to add: Compressed (7z) the download size would be around ~44 MB. I measured on Windows with a Qt Creator built with WebEngine support and surfed a little through the docs. The memory consumption of the web engine process weighed in between 14-20 MB of RAM. So it looks like this AFAICS: * We would be adding 145 MB of additional disk usage * We would add ~44 MB to the download size of Qt Creator * We would eat ~14-20 MB of additional RAM (not quite fair though, as we'd have to subtract the QTextDocument memory usage for a diff). I don't quite share the opinion that these are "beastly" numbers for desktop machines running C++ development environments. I think that they are worth it. In exchange we can show external content like cppreference or cmake docs without having to worry about their rendering, we can get rid of our separate style sheets and workarounds and we can render the Qt documentation the same way as on the website. We can eliminate an entire class of problems, and we can still prevent such content from accessing remote websites. We've had this situation for a long time now and I think that we should finally move forward and give our users better quality at the expense of their disk space, memory consumption and download size. Simon ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
Am 25.06.19 um 10:10 schrieb Morten Sørvig: > I’m not sure if it has been mentioned; we have another option which is to use > the OS web browser component via the Qt WebView module. > > The benefits would be > > * up-to-date web browser (and someone else keeps it up to date for us) > * insignificant additional download size > * no trouble with restricted platforms where shipping a full web browser is > not feasible (but then maybe creator isn’t going to run on those platforms, > anyway) > > QWebView’s platform coverage may be insufficient for Creator, which means > > * no html docs on those platforms :( > * or, we expand QWebView platform coverage > * or, QT WebView does have a WebEngine backend I think that would indeed be desirable in the long run. At the moment this is limited to macOS (and from the looks of it, Qt Creator has direct support for using WebKit on macOS, but oddly my build doesn't have it enabled?). I'm quite excited about Microsoft's WebView2 development that could become a very nice backend for QWebView on Windows. I played with it the other day and it looks quite nice. The deployment model is not suitable for us at the moment (nuget only) and it's still in an early release phase. However it comes with a powerful API and an opt-in evergreen distribution model. QWebView would also need to be improved to support feeding custom data into it, unless somebody implements serving via a local http server. I think these are all options in the future. Simon ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
Il 25/06/19 10:12, Simon Hausmann ha scritto: I think you're right, the linkage appears to be due to the use of QQuickWidget as child widget of QWebEngineView. Do you think that's a problem? I don't really know :) I was asking about feedback regarding reintroducing a mandatory Qt Quick dependency after Creator decided to drop it in certain parts. (Didn't want to answer "works for me so I don't see the problem"). My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
Hi, I think you're right, the linkage appears to be due to the use of QQuickWidget as child widget of QWebEngineView. Do you think that's a problem? Simon From: Giuseppe D'Angelo Sent: Tuesday, June 25, 2019 10:02 To: Simon Hausmann; development@qt-project.org Subject: Re: [Development] Assistant WebKit/WebEngine support Hi, Il 25/06/19 09:26, Simon Hausmann ha scritto: > > QtQuick 2 is not required for using WebEngine and there is support for > software rendering. The existing Qt Creator integration as well as the > proposed patch to Qt Assistant to use Web Engine is using the widgets > integration. > > To put it to a test, I just installed a fresh Windows 10 in VirtualBox > on my Linux Box, installed VS, Qt Creator and Qt 5.13 and compiled the > web engine widgets simple browser example. It built and ran out of the > box inside the virtual machine and I could browser qt.io and doc.qt.io. [citation needed], though: why is QtWebEngine linking against Qt Quick? > $ readelf -d libQt5WebEngineWidgets.so > > Dynamic section at offset 0x3eab0 contains 46 entries: > TagType Name/Value > 0x0001 (NEEDED) Shared library: > [libQt5WebEngineCore.so.5] > 0x0001 (NEEDED) Shared library: [libQt5Quick.so.5] > 0x0001 (NEEDED) Shared library: > [libQt5PrintSupport.so.5] > 0x0001 (NEEDED) Shared library: [libQt5Widgets.so.5] > 0x0001 (NEEDED) Shared library: [libQt5Gui.so.5] > 0x0001 (NEEDED) Shared library: > [libQt5WebChannel.so.5] > 0x0001 (NEEDED) Shared library: [libQt5Qml.so.5] > 0x0001 (NEEDED) Shared library: [libQt5Network.so.5] > 0x0001 (NEEDED) Shared library: > [libQt5Positioning.so.5] > 0x0001 (NEEDED) Shared library: [libQt5Core.so.5] > 0x0001 (NEEDED) Shared library: [libpthread.so.0] > 0x0001 (NEEDED) Shared library: > [libQt5QuickWidgets.so.5] > 0x0001 (NEEDED) Shared library: [libGL.so.1] > 0x0001 (NEEDED) Shared library: [libstdc++.so.6] > 0x0001 (NEEDED) Shared library: [libm.so.6] > 0x0001 (NEEDED) Shared library: [libgcc_s.so.1] > 0x0001 (NEEDED) Shared library: [libc.so.6] > 0x000e (SONAME) Library soname: > [libQt5WebEngineWidgets.so.5] > 0x001d (RUNPATH)Library runpath: [$ORIGIN] [snip] The software renderer path should be discussed with the authors of the other Qt Quick-based plugins inside Creator (as currently the decision of using software rendering is process-wide). My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
> On 24 Jun 2019, at 22:44, Lars Knoll wrote: > > >> On 24 Jun 2019, at 21:54, Tor Arne Vestbø wrote: >> >> >> >>> On 24 Jun 2019, at 14:43, Simon Hausmann wrote: >>> >>> I have two more numbers to add: Compressed (7z) the download size would >>> be around ~44 MB. I measured on Windows with a Qt Creator built with >>> WebEngine support and surfed a little through the docs. The memory >>> consumption of the web engine process weighed in between 14-20 MB of RAM. >>> >>> So it looks like this AFAICS: >>> >>> * We would be adding 145 MB of additional disk usage >>> >>> * We would add ~44 MB to the download size of Qt Creator >>> >>> * We would eat ~14-20 MB of additional RAM (not quite fair though, >>> as we'd have to subtract the QTextDocument memory usage for a diff). >>> >>> >>> I don't quite share the opinion that these are "beastly" numbers for >>> desktop machines running C++ development environments. I think that they >>> are worth it. In exchange we can show external content like cppreference >>> or cmake docs without having to worry about their rendering, we can get >>> rid of our separate style sheets and workarounds and we can render the >>> Qt documentation the same way as on the website. We can eliminate an >>> entire class of problems, and we can still prevent such content from >>> accessing remote websites. >>> >>> >>> We've had this situation for a long time now and I think that we should >>> finally move forward and give our users better quality at the expense of >>> their disk space, memory consumption and download size. >>> >> >> I fully agree with this. Thanks for the numbers Simon! > > Another +1 from me. Let’s stop fighting this. We need something that can > properly display any HTML content (and maybe PDF and things as well) that we > throw at it. > I’m not sure if it has been mentioned; we have another option which is to use the OS web browser component via the Qt WebView module. The benefits would be * up-to-date web browser (and someone else keeps it up to date for us) * insignificant additional download size * no trouble with restricted platforms where shipping a full web browser is not feasible (but then maybe creator isn’t going to run on those platforms, anyway) QWebView’s platform coverage may be insufficient for Creator, which means * no html docs on those platforms :( * or, we expand QWebView platform coverage * or, QT WebView does have a WebEngine backend Cheers, Morten ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
Hi, Il 25/06/19 09:26, Simon Hausmann ha scritto: QtQuick 2 is not required for using WebEngine and there is support for software rendering. The existing Qt Creator integration as well as the proposed patch to Qt Assistant to use Web Engine is using the widgets integration. To put it to a test, I just installed a fresh Windows 10 in VirtualBox on my Linux Box, installed VS, Qt Creator and Qt 5.13 and compiled the web engine widgets simple browser example. It built and ran out of the box inside the virtual machine and I could browser qt.io and doc.qt.io. [citation needed], though: why is QtWebEngine linking against Qt Quick? $ readelf -d libQt5WebEngineWidgets.so Dynamic section at offset 0x3eab0 contains 46 entries: TagType Name/Value 0x0001 (NEEDED) Shared library: [libQt5WebEngineCore.so.5] 0x0001 (NEEDED) Shared library: [libQt5Quick.so.5] 0x0001 (NEEDED) Shared library: [libQt5PrintSupport.so.5] 0x0001 (NEEDED) Shared library: [libQt5Widgets.so.5] 0x0001 (NEEDED) Shared library: [libQt5Gui.so.5] 0x0001 (NEEDED) Shared library: [libQt5WebChannel.so.5] 0x0001 (NEEDED) Shared library: [libQt5Qml.so.5] 0x0001 (NEEDED) Shared library: [libQt5Network.so.5] 0x0001 (NEEDED) Shared library: [libQt5Positioning.so.5] 0x0001 (NEEDED) Shared library: [libQt5Core.so.5] 0x0001 (NEEDED) Shared library: [libpthread.so.0] 0x0001 (NEEDED) Shared library: [libQt5QuickWidgets.so.5] 0x0001 (NEEDED) Shared library: [libGL.so.1] 0x0001 (NEEDED) Shared library: [libstdc++.so.6] 0x0001 (NEEDED) Shared library: [libm.so.6] 0x0001 (NEEDED) Shared library: [libgcc_s.so.1] 0x0001 (NEEDED) Shared library: [libc.so.6] 0x000e (SONAME) Library soname: [libQt5WebEngineWidgets.so.5] 0x001d (RUNPATH)Library runpath: [$ORIGIN] [snip] The software renderer path should be discussed with the authors of the other Qt Quick-based plugins inside Creator (as currently the decision of using software rendering is process-wide). My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
25.06.2019, 10:48, "André Pönitz" :
> On Mon, Jun 24, 2019 at 04:37:16PM +0300, Konstantin Tokarev wrote:
>> > I have two more numbers to add: Compressed (7z) the download size would
>> > be around ~44 MB. I measured on Windows with a Qt Creator built with
>> > WebEngine support and surfed a little through the docs. The memory
>> > consumption of the web engine process weighed in between 14-20 MB of RAM.
>> >
>> > So it looks like this AFAICS:
>> >
>> > * We would be adding 145 MB of additional disk usage
>> >
>> > * We would add ~44 MB to the download size of Qt Creator
>> >
>> > * We would eat ~14-20 MB of additional RAM (not quite fair though,
>> > as we'd have to subtract the QTextDocument memory usage for a diff).
>>
>> For comparison, numbers for QtWebKit are: 84 MB of disk space (of which
>> 26 MB is taken by ICU data), and 20 MB when compressed to 7z archive.
>> I didn't measure RAM consumption, but I'm sure it won't take more than
>> you've measured.
>>
>> This is full build with all features enabled; it's possible to make reduced
>> build without multimedia support, JavaScript JIT and other features not
>> needed
>> for help browser.
>
> I actually tried that a while ago (i.e. clone Qt Webkit and throw out
> everything that's not needed to display Qt's help) when the shift to
> WebEngine was looming.
>
> It worked up to a certain degree nicely in the build system by
> de-selecting options, than quite a bit more by actually removing code.
> Getting rid of all of JS was not obviously possible.
Removing code makes result unmaintainable, while minimal configuration with
existing options makes a good balance IMO.
>
> The result was ok-ish size-wise (and for me definitely preferable over
> WebEngine) but the question is where to put to cut. In some setups
> ("Want to see DevDays videos") even cutting multimedia plugins won't be
> accepted by everyone. I.e. the "need" for a "full browser" is likely
> to always exist, and that's currently served by "use external help".
We have MediaFoundation player on Windows these days so it can work
without pulling in Qt Multimedia and uses system-provided codecs, so
enabling multimedia won't add that much. However, for multimedia content
there is always an option to add external link, as this is not the kind of
documentation you really need to have inside your IDE or in similar context.
--
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
Hi, I don't think that support for x86 macOS will be retroactively added, especially since upstream as well as Apple are dropping x86. MinGW is also not a supported compiler, but it's possible to build with clang-cl, which is what upstream is using. (Interestingly, Safari, FireFox and Chrome are all built using clang these days) Simon From: Development on behalf of Konrad Rosenbaum Sent: Tuesday, June 25, 2019 7:50 To: development@qt-project.org Subject: Re: [Development] Assistant WebKit/WebEngine support Hi, On 6/24/19 2:43 PM, Simon Hausmann wrote: > We've had this situation for a long time now and I think that we should > finally move forward and give our users better quality at the expense of > their disk space, memory consumption and download size. ...at the risk of making enemies: so the platform issues(*) will be solved till Qt 6.0? So, even if I try to compile Qt myself on, say MinGW or 32bit MacOS - I will end up with a (fully?) functional Assistant? (*)https://doc.qt.io/qt-5/qtwebengine-platform-notes.html Konrad ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
Hi, QtQuick 2 is not required for using WebEngine and there is support for software rendering. The existing Qt Creator integration as well as the proposed patch to Qt Assistant to use Web Engine is using the widgets integration. To put it to a test, I just installed a fresh Windows 10 in VirtualBox on my Linux Box, installed VS, Qt Creator and Qt 5.13 and compiled the web engine widgets simple browser example. It built and ran out of the box inside the virtual machine and I could browser qt.io and doc.qt.io. Simon From: Development on behalf of Giuseppe D'Angelo via Development Sent: Monday, June 24, 2019 15:52 To: development@qt-project.org Subject: Re: [Development] Assistant WebKit/WebEngine support Here's a third question: On 24/06/2019 11:42, Palaraja, Kavindra wrote: > Two further questions: > > * What exactly is so big about WebEngine? What is this size that many are > hinting at but won't provide the number? > * Doesn't WebEngine have a feature where you can completely lock it out of > the Internet? Does using QtWebEngine still mean firing QQ2 under the hood and the subsequent OpenGL integration? That's known to be extremely flaky (and one of the reasons why Qt Creator dropped QQ2 for its welcome screen), My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
Hi, On 6/24/19 2:43 PM, Simon Hausmann wrote: > We've had this situation for a long time now and I think that we should > finally move forward and give our users better quality at the expense of > their disk space, memory consumption and download size. ...at the risk of making enemies: so the platform issues(*) will be solved till Qt 6.0? So, even if I try to compile Qt myself on, say MinGW or 32bit MacOS - I will end up with a (fully?) functional Assistant? (*)https://doc.qt.io/qt-5/qtwebengine-platform-notes.html Konrad pEpkey.asc Description: application/pgp-keys ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On 24/06/2019 22:44, Lars Knoll wrote: Another +1 from me. Let’s stop fighting this. We need something that can properly display any HTML content (and maybe PDF and things as well) that we throw at it. Thank you. Bastiaan. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On Mon, Jun 24, 2019 at 01:49:12PM +, Palaraja, Kavindra wrote: > +1, because: > > * It's 2019, we need to change with the times as documentation, especially > how content looks and feels, has come really far from those days. > * Almost 1:1 appearance of documentation in Creator vs. Browser. > * Nobody needs to patch QTextBrowser and fix CSS now > * We will get code snippet colouring for free in Creator > * We will finally be able to render a table like it should, with real borders > and alternating row colours, instead of the weird structure we have now None of that leads to the conclusinons that (a) the "integrated Webbrowser" needs to be WebEngine (b) it need to be mandatory. Andre' ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
> On 24 Jun 2019, at 21:54, Tor Arne Vestbø wrote: > > > >> On 24 Jun 2019, at 14:43, Simon Hausmann wrote: >> >> I have two more numbers to add: Compressed (7z) the download size would >> be around ~44 MB. I measured on Windows with a Qt Creator built with >> WebEngine support and surfed a little through the docs. The memory >> consumption of the web engine process weighed in between 14-20 MB of RAM. >> >> So it looks like this AFAICS: >> >>* We would be adding 145 MB of additional disk usage >> >>* We would add ~44 MB to the download size of Qt Creator >> >>* We would eat ~14-20 MB of additional RAM (not quite fair though, >> as we'd have to subtract the QTextDocument memory usage for a diff). >> >> >> I don't quite share the opinion that these are "beastly" numbers for >> desktop machines running C++ development environments. I think that they >> are worth it. In exchange we can show external content like cppreference >> or cmake docs without having to worry about their rendering, we can get >> rid of our separate style sheets and workarounds and we can render the >> Qt documentation the same way as on the website. We can eliminate an >> entire class of problems, and we can still prevent such content from >> accessing remote websites. >> >> >> We've had this situation for a long time now and I think that we should >> finally move forward and give our users better quality at the expense of >> their disk space, memory consumption and download size. >> > > I fully agree with this. Thanks for the numbers Simon! Another +1 from me. Let’s stop fighting this. We need something that can properly display any HTML content (and maybe PDF and things as well) that we throw at it. Not having a fully working engine will always lead to issues where this causes lots of additional work in other places, e.g. for the documentation team that has to tweak the content of our qch files. Currently our inline docs in Creator look a lot worse than the web version and lack many features that we have on the web based docs. How come we accept that? We do want integrated help and we want it to look good. That means we have to simply accept the fact that we’ll need an integrated browser. Cheers, Lars ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On Mon, Jun 24, 2019 at 04:37:16PM +0300, Konstantin Tokarev wrote:
> > I have two more numbers to add: Compressed (7z) the download size would
> > be around ~44 MB. I measured on Windows with a Qt Creator built with
> > WebEngine support and surfed a little through the docs. The memory
> > consumption of the web engine process weighed in between 14-20 MB of RAM.
> >
> > So it looks like this AFAICS:
> >
> > * We would be adding 145 MB of additional disk usage
> >
> > * We would add ~44 MB to the download size of Qt Creator
> >
> > * We would eat ~14-20 MB of additional RAM (not quite fair though,
> > as we'd have to subtract the QTextDocument memory usage for a diff).
>
> For comparison, numbers for QtWebKit are: 84 MB of disk space (of which
> 26 MB is taken by ICU data), and 20 MB when compressed to 7z archive.
> I didn't measure RAM consumption, but I'm sure it won't take more than
> you've measured.
>
> This is full build with all features enabled; it's possible to make reduced
> build without multimedia support, JavaScript JIT and other features not needed
> for help browser.
I actually tried that a while ago (i.e. clone Qt Webkit and throw out
everything that's not needed to display Qt's help) when the shift to
WebEngine was looming.
It worked up to a certain degree nicely in the build system by
de-selecting options, than quite a bit more by actually removing code.
Getting rid of all of JS was not obviously possible.
The result was ok-ish size-wise (and for me definitely preferable over
WebEngine) but the question is where to put to cut. In some setups
("Want to see DevDays videos") even cutting multimedia plugins won't be
accepted by everyone. I.e. the "need" for a "full browser" is likely
to always exist, and that's currently served by "use external help".
Andre'
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
I see that situation has improved somewhat since I've last tried to use cppreference qch in Qt Creator about a year ago, but the formatting still sometimes goes crazy (especially with "since C++XY" in the overload list), and there are some issues with font aliasing. I.e. there are definitely many ways it can be improved, compared to the web version. пн, 24 июн. 2019 г. в 16:49, Cristian Adam : > > -Original Message- > > From: Development On Behalf Of > > Simon Hausmann > > Sent: Monday, 24 June 2019 14:44 > > To: development@qt-project.org > > Subject: Re: [Development] Assistant WebKit/WebEngine support > > > > > > > > I don't quite share the opinion that these are "beastly" numbers for > > desktop machines running C++ development environments. I think that they > > are worth it. In exchange we can show external content like cppreference > > or cmake docs without having to worry about their rendering, we can get > > rid of our separate style sheets and workarounds and we can render the > > Qt documentation the same way as on the website. We can eliminate an > > entire class of problems, and we can still prevent such content from > > accessing remote websites. > > > > CMake[1] and cppreference [2] websites do offer QCH help files for offline > browsing in Qt Creator. Setting them up it's the step that probably not so > many users are doing. > > Would it be possible to have a Qt Webengine Lite, which would include only > the functionality needed by QtHelp? > > Alternatively one can have something like https://github.com/litehtml/, > which seems to have more web support than QTextBrowser, but far away from > what a real web browser can support. > > Cheers, > Cristian. > > [1] https://cmake.org/cmake/help/v3.15/CMake.qch > [2] https://en.cppreference.com/w/File:qch_book_20190607.zip > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
Here's a third question: On 24/06/2019 11:42, Palaraja, Kavindra wrote: Two further questions: * What exactly is so big about WebEngine? What is this size that many are hinting at but won't provide the number? * Doesn't WebEngine have a feature where you can completely lock it out of the Internet? Does using QtWebEngine still mean firing QQ2 under the hood and the subsequent OpenGL integration? That's known to be extremely flaky (and one of the reasons why Qt Creator dropped QQ2 for its welcome screen), My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: S/MIME Cryptographic Signature ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
+1, because: * It's 2019, we need to change with the times as documentation, especially how content looks and feels, has come really far from those days. * Almost 1:1 appearance of documentation in Creator vs. Browser. * Nobody needs to patch QTextBrowser and fix CSS now * We will get code snippet colouring for free in Creator * We will finally be able to render a table like it should, with real borders and alternating row colours, instead of the weird structure we have now Kavindra On 24.06.19, 14:55, "Development on behalf of Tor Arne Vestbø" wrote: > On 24 Jun 2019, at 14:43, Simon Hausmann wrote: > > I have two more numbers to add: Compressed (7z) the download size would > be around ~44 MB. I measured on Windows with a Qt Creator built with > WebEngine support and surfed a little through the docs. The memory > consumption of the web engine process weighed in between 14-20 MB of RAM. > > So it looks like this AFAICS: > > * We would be adding 145 MB of additional disk usage > > * We would add ~44 MB to the download size of Qt Creator > > * We would eat ~14-20 MB of additional RAM (not quite fair though, > as we'd have to subtract the QTextDocument memory usage for a diff). > > > I don't quite share the opinion that these are "beastly" numbers for > desktop machines running C++ development environments. I think that they > are worth it. In exchange we can show external content like cppreference > or cmake docs without having to worry about their rendering, we can get > rid of our separate style sheets and workarounds and we can render the > Qt documentation the same way as on the website. We can eliminate an > entire class of problems, and we can still prevent such content from > accessing remote websites. > > > We've had this situation for a long time now and I think that we should > finally move forward and give our users better quality at the expense of > their disk space, memory consumption and download size. > I fully agree with this. Thanks for the numbers Simon! Tor Arne ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development 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
Re: [Development] Assistant WebKit/WebEngine support
> -Original Message- > From: Development On Behalf Of > Simon Hausmann > Sent: Monday, 24 June 2019 14:44 > To: development@qt-project.org > Subject: Re: [Development] Assistant WebKit/WebEngine support > > > > I don't quite share the opinion that these are "beastly" numbers for > desktop machines running C++ development environments. I think that they > are worth it. In exchange we can show external content like cppreference > or cmake docs without having to worry about their rendering, we can get > rid of our separate style sheets and workarounds and we can render the > Qt documentation the same way as on the website. We can eliminate an > entire class of problems, and we can still prevent such content from > accessing remote websites. > CMake[1] and cppreference [2] websites do offer QCH help files for offline browsing in Qt Creator. Setting them up it's the step that probably not so many users are doing. Would it be possible to have a Qt Webengine Lite, which would include only the functionality needed by QtHelp? Alternatively one can have something like https://github.com/litehtml/, which seems to have more web support than QTextBrowser, but far away from what a real web browser can support. Cheers, Cristian. [1] https://cmake.org/cmake/help/v3.15/CMake.qch [2] https://en.cppreference.com/w/File:qch_book_20190607.zip ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
