Re: [Development] CSS styling, XML, HTML etc. (was Re: Assistant WebKit/WebEngine support)
21.05.2019, 19:03, "Bastiaan Veelo" : > [skipping many interesting points, sorry] > > On 21/05/2019 16:06, Shawn Rutledge wrote: >> Anyway I think Assistant is one of those cases where I would prefer to >> keep using QTextBrowser and fix it up a bit more to suit, rather than >> switching to a real browser engine. Light weight is a real advantage. >> Creator already takes up enough memory as it is, with its code model >> especially. And documentation doesn’t need most of the fancy HTML >> features either. > > A better QTextBrowser would be very much welcomed, but there may still > be cases where Assistant needs more features. > > The question of what HTML features are necessary depends on the > application. In user applications, Assistant is not used to display code > documentation (which is quite simple) but help files, which may require > a much greater feature set. If it were possible, it could even be > desirable to include small video clips as instructions for performing > certain tasks. So there may still be applications where a full browser > stack would be desirable. One could argue that one should spawn a real > browser instead, but the index and search facilities in Assistant are > invaluable. FWIW, size-optimized build of QtWebKit with minimal feature set resulted in ~20M binary here, though I've disabled video. While it can be seen aas bloated when compared to QTextBrowser, it includes much more advanced HTML/CSS renderer, supports JavaScript, and includes full-fledged SVG renderer. -- Regards, Konstantin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CSS styling, XML, HTML etc. (was Re: Assistant WebKit/WebEngine support)
21.05.2019, 18:01, "Jean-Michaël Celerier" : >> (of all Qt applications, only a minority use either QSS or CSS) > > Are there sources for that ? From what I can see it has plenty of usage. > https://github.com/search?l=C%2B%2B=setStyleSheet=Code Also, it's possible to start any Qt application with -stylesheet, and there are users which use this feature even if application author never envisioned this. -- Regards, Konstantin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CSS styling, XML, HTML etc. (was Re: Assistant WebKit/WebEngine support)
[skipping many interesting points, sorry] On 21/05/2019 16:06, Shawn Rutledge wrote: Anyway I think Assistant is one of those cases where I would prefer to keep using QTextBrowser and fix it up a bit more to suit, rather than switching to a real browser engine. Light weight is a real advantage. Creator already takes up enough memory as it is, with its code model especially. And documentation doesn’t need most of the fancy HTML features either. A better QTextBrowser would be very much welcomed, but there may still be cases where Assistant needs more features. The question of what HTML features are necessary depends on the application. In user applications, Assistant is not used to display code documentation (which is quite simple) but help files, which may require a much greater feature set. If it were possible, it could even be desirable to include small video clips as instructions for performing certain tasks. So there may still be applications where a full browser stack would be desirable. One could argue that one should spawn a real browser instead, but the index and search facilities in Assistant are invaluable. -- Bastiaan. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CSS styling, XML, HTML etc. (was Re: Assistant WebKit/WebEngine support)
Am 21.05.2019 um 14:06 hat Shawn Rutledge geschrieben: I wish that were true for me. We need colours in table cell borders and SVG images (and better CSS support would be real nice). This might help, but is stalled: https://codereview.qt-project.org/c/qt/qtbase/+/177256 I was just putting some thought into CSS over the last few days, but wasn’t aware of that patch. Yes, I was always hoping to get it into the next Qt release (so I don't always have to patch Qt for my projects where this code is in use for years now). But it looks like there's not too much interest. I really wouldn't mind getting more reviewers for this so please feel invited ;-) Nils signature.asc Description: PGP signature ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CSS styling, XML, HTML etc. (was Re: Assistant WebKit/WebEngine support)
> (of all Qt applications, only a minority use either QSS or CSS) Are there sources for that ? From what I can see it has plenty of usage. https://github.com/search?l=C%2B%2B=setStyleSheet=Code Best, --- Jean-Michaël Celerier http://www.jcelerier.name On Tue, May 21, 2019 at 4:07 PM Shawn Rutledge wrote: > > > On 20 May 2019, at 18:56, Bastiaan Veelo wrote: > > > > On 20/05/2019 17:56, Konstantin Tokarev wrote: > >> 20.05.2019, 18:27, "Bastiaan Veelo" : > >>> On 20/05/2019 16:51, Konstantin Tokarev wrote: > >>> ... > >> However, it would better to avoid duplicating work with Qt Creator, > >> which also implements HelpViewer interface with different backends. > >> Some time ago there was a discussion that such shared interface & plugin > >> system should belong to Qt Web View module. But that would probably > >> require more work to be done. > > If there is really a need to use WebEngine, a plugin makes sense. Sharing > a plugin between Creator and Assistant makes sense. But I do worry about > the runtime memory bloat that it will introduce. > > >>> Or do you think that removing WebKit support from Assistant completely > >>> would be better, if WebEngine shows to be working well? > >> As for me, I'm totally fine with QTextBrowser > > > > I wish that were true for me. We need colours in table cell borders and > SVG images (and better CSS support would be real nice). This might help, > but is stalled: https://codereview.qt-project.org/c/qt/qtbase/+/177256 > > I was just putting some thought into CSS over the last few days, but > wasn’t aware of that patch. > > I don’t like the limitation we have, that CSS can be applied only while > parsing HTML, because after the parsing is done, there is no DOM: a lot of > structural information from HTML is lost. This is a limiting factor for my > work with supporting Markdown in QTD lately: after you have read HTML, not > enough information is saved to be able to write markdown as nicely as I’d > like (it’s mostly possible to work around, but e.g. results in a > separate block per line, and results in an indented plain > paragraph, so the markdown writer has to reconstruct some of the structure > by detecting those idiosyncrasies). And of course there’s no support for > applying CSS to markdown, precisely because of the fact that it can be > applied only while the HTML parser is running, and in the markdown case > there’s no HTML parser instance. I’m loathe to take the same approach with > markdown (apply CSS only while parsing), but I’d like to have CSS support > for it. For both HTML and Markdown it would be nice if CSS could be > applied dynamically to an existing QTextDocument. I don’t see a real > reason why we shouldn’t be able to, as long as QTD stores enough > information about the original structure (i.e. is not just a block > with a particular font size and style: > 310daae53926628f80c08e4415b94b90ad525c8f took care of that, because I > couldn’t realistically get started with markdown support unless the heading > blocks could at least remember their own heading levels). Similar fixes > could gradually turn QTD into something almost like a DOM, and could also > turn the HTML-writing support into a lot less of a mess (be able to write > out HTML that looks more like what you read in). But it’s kindof > frustrating work: I just keep wondering why stuff like that still needs to > be done in 2019. > > So I wonder if we should gradually fix that, or we would be better off > replacing the guts of QTD with a proper DOM of some sort. But of course > it’s a slippery slope: QTextBrowser should never be as complex as a real > browser. So the knee-jerk reaction is to say “forget about it, use > webengine”; but the other side of the argument is that it’s quite nice to > have such a compact implementation as QTD/QTB are, and there are so many > applications where a real browser engine is such terrible overkill. I > suspect that Konqueror must have had a time period where it had a suitably > compact but architecturally better design, but I haven’t dug in deep enough > to figure that out; several people should already know, anyway. > > BTW, there is a movement to ditch qtxmlpatterns and replace it in the one > use case that matters to Qt Quick (XmlListModel) with some other XML > parser, something good enough for all use cases in the rest of Qt. (Based > on libxml2 maybe?) So can we perhaps say these things are related: it’s OK > to support only well-formed XHTML, not loosely-structured HTML, maybe we > could use the same XML parser for both use cases, to reduce the code size > and get a real DOM at the same time? But it doesn’t make the CSS work any > easier; the question is how much would QTD change if we take that > approach. And the DOM in qtxmlpatterns seems kindof cool too > (feature-wise, although I don’t know much about the implementation); it’s > just that nobody wants to support it. But libxml2 has a DOM too, they > say. (I haven’t
[Development] CSS styling, XML, HTML etc. (was Re: Assistant WebKit/WebEngine support)
> On 20 May 2019, at 18:56, Bastiaan Veelo wrote: > > On 20/05/2019 17:56, Konstantin Tokarev wrote: >> 20.05.2019, 18:27, "Bastiaan Veelo" : >>> On 20/05/2019 16:51, Konstantin Tokarev wrote: >>> ... >> However, it would better to avoid duplicating work with Qt Creator, >> which also implements HelpViewer interface with different backends. >> Some time ago there was a discussion that such shared interface & plugin >> system should belong to Qt Web View module. But that would probably >> require more work to be done. If there is really a need to use WebEngine, a plugin makes sense. Sharing a plugin between Creator and Assistant makes sense. But I do worry about the runtime memory bloat that it will introduce. >>> Or do you think that removing WebKit support from Assistant completely >>> would be better, if WebEngine shows to be working well? >> As for me, I'm totally fine with QTextBrowser > > I wish that were true for me. We need colours in table cell borders and SVG > images (and better CSS support would be real nice). This might help, but is > stalled: https://codereview.qt-project.org/c/qt/qtbase/+/177256 I was just putting some thought into CSS over the last few days, but wasn’t aware of that patch. I don’t like the limitation we have, that CSS can be applied only while parsing HTML, because after the parsing is done, there is no DOM: a lot of structural information from HTML is lost. This is a limiting factor for my work with supporting Markdown in QTD lately: after you have read HTML, not enough information is saved to be able to write markdown as nicely as I’d like (it’s mostly possible to work around, but e.g. results in a separate block per line, and results in an indented plain paragraph, so the markdown writer has to reconstruct some of the structure by detecting those idiosyncrasies). And of course there’s no support for applying CSS to markdown, precisely because of the fact that it can be applied only while the HTML parser is running, and in the markdown case there’s no HTML parser instance. I’m loathe to take the same approach with markdown (apply CSS only while parsing), but I’d like to have CSS support for it. For both HTML and Markdown it would be nice if CSS could be applied dynamically to an existing QTextDocument. I don’t see a real reason why we shouldn’t be able to, as long as QTD stores enough information about the original structure (i.e. is not just a block with a particular font size and style: 310daae53926628f80c08e4415b94b90ad525c8f took care of that, because I couldn’t realistically get started with markdown support unless the heading blocks could at least remember their own heading levels). Similar fixes could gradually turn QTD into something almost like a DOM, and could also turn the HTML-writing support into a lot less of a mess (be able to write out HTML that looks more like what you read in). But it’s kindof frustrating work: I just keep wondering why stuff like that still needs to be done in 2019. So I wonder if we should gradually fix that, or we would be better off replacing the guts of QTD with a proper DOM of some sort. But of course it’s a slippery slope: QTextBrowser should never be as complex as a real browser. So the knee-jerk reaction is to say “forget about it, use webengine”; but the other side of the argument is that it’s quite nice to have such a compact implementation as QTD/QTB are, and there are so many applications where a real browser engine is such terrible overkill. I suspect that Konqueror must have had a time period where it had a suitably compact but architecturally better design, but I haven’t dug in deep enough to figure that out; several people should already know, anyway. BTW, there is a movement to ditch qtxmlpatterns and replace it in the one use case that matters to Qt Quick (XmlListModel) with some other XML parser, something good enough for all use cases in the rest of Qt. (Based on libxml2 maybe?) So can we perhaps say these things are related: it’s OK to support only well-formed XHTML, not loosely-structured HTML, maybe we could use the same XML parser for both use cases, to reduce the code size and get a real DOM at the same time? But it doesn’t make the CSS work any easier; the question is how much would QTD change if we take that approach. And the DOM in qtxmlpatterns seems kindof cool too (feature-wise, although I don’t know much about the implementation); it’s just that nobody wants to support it. But libxml2 has a DOM too, they say. (I haven’t looked at the API yet.) Another reason CSS came up is in the context of what to do with QStyle in Qt 6. QSS is another thing that Qt developers have always been loathe to support, and yet the users keep on using it. But there is a case where CSS can really be applied at runtime. It has a reputation for being terrible for performance, but I didn’t really understand why until looking at a bug a couple of
