On Wednesday, 19 August 2026 04:21:13 Pacific Daylight Time Ulf Hermann via Development wrote: > > That's why we have per-feature defines you can choose from (QT_NO_QPAIR, > > QT_NO_CONTEXTLESS_CONNECT, QT_NO_FOREACH, QT_NO_KEYWORDS). That's what I > > was proposing. > > The number of QT_NO_FOO you have to type to be somewhat safe from your > own stupidity is clearly getting out of hand, as we can already see from > this statement alone. In QML we also have individual pragmas for all the > individual practices, and it's not sustainable. That's where my > suggestion about version-based profiles comes from.
Agreed it's getting unwieldy. A "version-based profile" can just be a .h that
you can #include in your code and is not master-included (syncqt) anywhere
else. Therefore, if you don't like the one we supply, you can deploy your own
in your project.
[Note how this conflicts with Modules]
> In addition, however, a preprocessor define won't cut it in the case of
> AutoText. The default textFormat for e.g. QLabel lives in qlabel_p.h
> which never sees a user #define. It's baked in when _Qt_ is compiled.
Understood. The point of my suggestion was to call a different overload of
QLabel::setText/constructor/etc. so that the library is told what the default
is. The simplest is to change the default parameter in the function.
Longer term, I like the idea of a different type wrapping the QString
indicating that it is AutoText - ideally then it escapes any formatting done
with {} or %1 such that formatting doesn't introduce new controls.
> > I personally don't look at those options. Do we even have them? I just
> > ignore those changes because I believe they are a flawed design. If
> > anyone asked my opinion on any such change, they'll get a -1.
>
> Which options? QT_NO_FOREACH etc? Well, that one is quite important I'd
> wager. On the whole they have the flaw that there are too many and you
> need to add them in too many places, but we might make an effort to fix
> that. See above.
The "profile" ones. Individual choices I am ok with.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCG - Platform & Sys. Eng.
smime.p7s
Description: S/MIME cryptographic signature
-- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
