> On 27 Jan 2016, at 13:34, mark diener <rpzrpz...@gmail.com> wrote: > > The other major problem is that QQuickItem does not allow for > QSGTextRect, so updatePaintNode CANNOT have text rendering > in coordination with QSGGeometry. The current recommendation is to > try to coordinate using signals between 2 different QQuickItems, 1 > with text, the other > with graphical geometry. This is a restriction that appears to have > occurred by chance.
That’s not the right class name AFAICT, but you mean you want public C++ API to populate text nodes into the scene graph, right? Following the pattern that QSGSimpleRectNode and QSGSimpleTextureNode are public. Yes this has been a sore thumb for quite some time. Meanwhile, you can use private API. If we make it public, then we are committed to keeping it compatible from now on, so I think that’s why the text-related nodes have not been made public so far: fear of losing flexibility to evolve. We know that text rendering in Qt Quick needs to be more efficient. What if that involves some refactoring? And text rendering is complex, more or less depending on how fancy layout you need. So I think in the long term we need some lower-level stuff, like a Glyph object in some QtQuick module (for putting FontAwesome icons [and future color-font icons!] on tool buttons, and selecting them by name rather than by unicode ID), and a PlainText item restricted to left-to-right rendering in a single font and color (no character spans, no markup, no harfbuzz, no RTL, but maybe with tab stops), as long as such an approach actually speeds up the common case. Maybe such simple classes will be easier to make public, too, because they will have thin API. (And then I would like to use the PlainText item to build a wicked-fast plain-text TableView.) But, I did this https://codereview.qt-project.org/#/c/125753/ because in addition to being private, QQuickTextNode wasn’t even exported from the module; that must have been an oversight. But that’s for 5.7. So at least you can work at the level of Items rather than scene-graph nodes, using private C++ API. And there is also private API for manipulating the scene graph nodes. This came up for me when I wanted to label the tick marks on the axes of a line graph. (I didn’t want to use bindings to position individual Text items.) I tried adding QT+=quick-private #include <private/qsgdistancefieldglyphnode_p.h> and managed to spit out a few glyphs, but realized that our layout API is a little cumbersome (and I found a bug while I was at it, which has since been fixed if memory serves), and figured I’d need more time than I thought to get it working well. So then I tried using QQuickTextNode instead, which works now (on 5.7 branch). But it’s not the fastest possible way to do simple left-to-right labelling, so I should probably go back to the first way at some point. And if you haven’t, you should try it too, and then be careful what kind of public API you wish for. ;-) > This cripples custom controls capabilities and forces me to explain to > customers about Qt limitations. > > So how can we get the header file for QQmlEngine changed for 5.7 What is that about? > feature freeze to add those 3 function declarations and un-sandbox > QSGTextRect > and still pass maintainer acceptance all by Monday? If nobody started that yet, that means it’s potentially 5.8 material, right? And as soon as dev is branched for 5.7, it implies that any further development on dev branch is actually for 5.8. So someone could potentially have a full half-year cycle to make the existing private APIs decent, and/or write the new stuff, debug it, document it, do API review, use it in some pet application(s), and catch all the gotcha’s. Assuming that everyone involved can be persuaded that it actually ought to be public at all, within that time frame, or assuming that somebody finds the time to implement APIs which are definitely good enough to make public and support over the long term. (I would like to actually, but my main goal for 5.8 is the set of new pointer handlers, which is notoriously time-consuming stuff: it’s hard to get reviewers to be interested and have sufficient attention span, autotests take a lot of work, etc.) > > Cheers, > > md > > > On Wed, Jan 27, 2016 at 2:30 AM, Knoll Lars <lars.kn...@theqtcompany.com> > wrote: >> Hi everybody, >> >> we’re slightly past the originally planned date for the feature freeze, for >> various reasons (new stuff being open sourced, license change and being late >> with 5.6). But I believe most things should be in place now to do the >> feature freeze for 5.7 next Monday. >> >> There are currently three exceptions to the freeze: >> >> * ok to finish the printing support in web engine >> * ok for BTLE support for Linux in qtconnectivity (merge neard branch) >> * Modules that are flagged as TP can also have some more time >> >> If anybody else has a feature he believes absolutely has to make it to 5.7, >> get it done until Monday or talk to me :) >> >> Cheers, >> Lars >> >> >> _______________________________________________ >> Development mailing list >> Development@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Interest mailing list > inter...@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
