Shawn: I went back an re-read your comments.
How do I submit something for Private API in 5.7 after feature-freeze date? This may be the mechanism that gives me time to try to code my feature addition and get it into the continous integration system and NOT be required to do the work before feature freeze 5.7 on Monday. Thanks, md On Wed, Jan 27, 2016 at 10:15 AM, Rutledge Shawn <shawn.rutle...@theqtcompany.com> wrote: > >> 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
