> (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&q=setStyleSheet&type=Code
Best, ------- Jean-Michaël Celerier http://www.jcelerier.name On Tue, May 21, 2019 at 4:07 PM Shawn Rutledge <shawn.rutle...@qt.io> wrote: > > > On 20 May 2019, at 18:56, Bastiaan Veelo <basti...@veelo.net> wrote: > > > > On 20/05/2019 17:56, Konstantin Tokarev wrote: > >> 20.05.2019, 18:27, "Bastiaan Veelo" <basti...@veelo.net>: > >>> 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. <pre> results in a > separate block per line, and <blockquote> 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. <H1> 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 days ago (QTBUG-73251). Still not sure how much of the > performance penalty is endemic to the architecture (doing lots of runtime > lookups in data structures to figure out what to do) vs. having a bit too > much delegation going on between different style classes, such that there > is even a loop detector to prevent infinite loops. Anyway QSS is a case > where the styling _is_ being applied at runtime, and that’s done by making > another subclass of StyleSelector… so I just barely started going in the > direction of maybe making another one that can try to apply styles directly > to QTD at runtime. But I’m doubtful about whether that could be a waste of > time if we end up deciding that the current CSS implementation should be > replaced, or changed drastically, or if QTD internals will be changed > drastically. > > Another idea: qml looks a bit like CSS, so maybe we should use QML for the > styling language (just the declarative syntax, no JS, no imperative syntax > at all). One disadvantage is that web developers know CSS, so this would > limit the opportunities for reusing stylesheets, and of course break > backwards compatibility with QSS; but I wonder if we could get away with > that, since these are minority use cases anyway (of all Qt applications, > only a minority use either QSS or CSS), and writing styles shouldn’t be too > hard (if it is, you’re making it too complicated). Maybe we could write a > converter or something. > > 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. > > > Footnote: I tried to do a hand-wavey translation of a trivial CSS file to > QML to see if the syntax could possibly make sense. Didn’t really think > about cascading or about CSS classes much, but the objects created by the > declarations could have “class” properties I guess. I don’t think QTD > supports CSS classes in HTML yet either (?) > > ---- > > a { text-decoration: none; color: #660066; } > body { font: normal 400 28px/1.2 times, serif; } > blockquote { > font: 32px italic helvetica, sans-serif; > margin-top: 10px; > margin-bottom: 10px; > margin-left: 50px; > padding-left: 15px; > border-left: 3px solid #ccc; > } > > ---- > > import QtStyle 1.0 // hypothetical plugin that defines objects to hold > CSS-like rules > > // To make this work, we should ideally add: > // - units in QML > // - colors can be unquoted > // - multiple font families to have fallback > // - should declarations be Capitalized even though HTML and CSS tags > often aren’t? > > Anchor { // Or A, because that's how it is in HTML? > font.underline: false > color: "#6600FF" // Just color? should it be font.color? > } > > Body { > font { > weight: Font.Normal > pixelSize: 28 > // size: 28px would be better > family: "Times" > // families: ["Times", "Serif"] // order of preference would be > better > italic: true > } > } > > Blockquote { // This declaration says "When you see a blockquote, style it > like this" > font { > pixelSize: 32 > family: "Helvetica" > italic: true > } > margin { > top: 10 > bottom: 10 > left: 50 > } > padding.left: 15 > Border { // This nested declaration probably creates something > (painter commands or SG node) > sides: Border.left > width: 3 > color: "#ccc" // ugh, I've always hated quoting colors: they > aren't strings! > } > } > > ---- > > Hmm which one would you rather write? ;-) QML is more familiar to > developers but also more verbose. > > _______________________________________________ > 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
