Hi,
I can definitely make it a compile-time option if that is the convention, but
we're not consistent about this in Qt. The usual reason for using environment
variables for developer options for me has been that the evaluation happens
inside the Qt library, and many users do not build Qt themselves (they either
get it from the installer, from the distro or some other system integrator).
Therefore, I usually prefer environment variables in cases where I know we are
likely to get a lot of reports looking to opt back into the old behavior
because they have a release next week etc. and compile-time options in cases
where we think the defaults will be perfectly fint for 99% but there might be
1% with very special customization needs.
Environment variables are also global, so in a host/plugin scenario the choice
would be made on behalf of components outside the one setting the variable.
Hmm. If we make the compile-time option only affect the plugin/application
binary and not the system-wide Qt libraries, that does change some things.
Something like this?
inline void setText(const QString &str)
{
setTextImpl(str);
}
// ...
private:
void setTextImpl(const QString &, Qt::TextFormat defaultFmt =
#if defined(QT_ALLOW_AUTOMATIC_RICH_TEXT)
Qt::AutoText
#else
Qt::PlainText
#endif
);
We still need the exported setText() for binary compatibility which sounds a
bit shaky. Is it guaranteed that the application will use the inlined function
and not bind to the exported symbol with the identical signature? Do we have
any examples where we did this type of thing before?
And is it worth making it this elaborate for the sake of plugin developers? I
very much agree that we should not forget about that use case. But for this
particular case, the preferred application-side solution is to update the text
components. The environment variable fail safe would only exist as a temporary
quick fix. In that case, maybe it's acceptable that there are some situations
where it does not work?
--
Eskil Abrahamsen Blomfeldt
Principal Manager, Graphics Engines
The Qt Company
Sandakerveien 116
0484 Oslo, Norway
[email protected]
http://qt.io
Confidential
________________________________
From: Tor Arne Vestbø <[email protected]>
Sent: Tuesday, November 3, 2026 3:14 PM
To: Eike Ziller <[email protected]>
Cc: Eskil Abrahamsen Blomfeldt <[email protected]>; List for
announcements regarding Qt releases and development via Announce via
Development <[email protected]>
Subject: Re: [Development] Changing the default of AutoText to PlainText
On 3 Nov 2026, at 14:38, Eike Ziller via Development
<[email protected]> wrote:
On 2. Nov 2026, at 16:00, Eskil Abrahamsen Blomfeldt via Development
<[email protected]<mailto:[email protected]>> wrote:
• Add run-time warning to Qt 6.12.x which triggers whenever AutoText gets
resolved to RichText/StyledText. This detects intentional use and alerts
developers that they need to update their code before the next minor release.
Work in progress for Qt Widgets here:
https://codereview.qt-project.org/c/qt/qtbase/+/784816
• Add compile-time warnings using qmllint and clazy to detect uses where
AutoText is used with either rich text or undeterminable (possibly
user-provided) text.
• Blog about it and try to spread the word as much as possible
• Change the default from AutoText to PlainText in Qt 6.13. Possibly with
an environment variable to manually select the old behavior.
Why an environment variable instead of a compile time define? (Like the
ASCII->QString auto-conversion options.) An environment variable sounds weird
to me for something that should be a developer decision.
Agreed. Environment variables are also global, so in a host/plugin scenario the
choice would be made on behalf of components outside the one setting the
variable.
Tor Arne
--
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
