> On 4. Nov 2026, at 10:01, Julien Cugnière <[email protected]> wrote: > > [You don't often get email from [email protected]. Learn why this is > important at https://aka.ms/LearnAboutSenderIdentification ] > > Le mer. 4 nov. 2026 à 08:53, Eskil Abrahamsen Blomfeldt via > Development <[email protected]> a écrit : >> 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. > > You could also do something similar to > QQuickWindow::setTextRenderType(). That way, people could go back to > the old behaviour with a single line change to their code, without > recompiling Qt, and without affecting other users of Qt.
Sounds good to me too (and takes effect without recompiling the whole application when testing). Could just be another Qt::AA_ .... application attribute. — Eike Ziller Principal Software Engineer The Qt Company GmbH Erich-Thilo-Str. 10 12489 Berlin, Germany [email protected] https://www.qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Juha Puputti Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
