[Development] QLibraryInfo::path(): to deprecate or not to deprecate?

[Edward Welbourne]

On Tuesday, 28 July 2026 02:08:24 Pacific Daylight Time Volker Hilsheimer via
Development wrote:
>> Getting the examples cleaned up is IMHO a precondition for
>> deprecating,

That sounds like an expectation to make explicit in [0].
I have added a quick sentence in the "think twice" section.

[0] https://wiki.qt.io/Deprecation

>> and the tests should disable the deprecation warning as otherwise we
>> get -Werror build failures. The examples are a fairly overviewable
>> list, but they should of course show the right pattern.

Thiago Macieira (28 July 2026 15:59) replied (inter alia)
> We get warnings in tests, not errors. Tests are compiled without
> -Werror.

I would, none the less, prefer to get rid of warnings also in tests.
I prefer to do that with overt QT_IGNORE_DEPRECATIONS() or

QT_WARNING_PUSH
QT_WARNING_DISABLE_DEPRECATED
...
QT_WARNING_POP

(within #if-ery on the same QT_DEPRECATED_SINCE() as the API being
tested, naturally).  I would rather not build tests with deprecation
warnings turned off in the compiler command-line - and it's not entirely
clear whether Volker meant the former or the latter by "disable the
deprecation warnings".

>> So the question is what the correct replacement for code like this is:
>>
>>     // from qtbase/examples/corelib/mimetypes/mimetypebrowser/main.cpp
>>     QTranslator translator;
>>     if (translator.load(QLocale::system(), "qtbase"_L1, "_"_L1,
>>                         QLibraryInfo::path(QLibraryInfo::TranslationsPath)))
>> { app.installTranslator(&translator);
>>     }
>>
>>
>> I assume the right pattern is using a while-loop until one of the
>> loads succeeded, rather than loading them all in a for-loop.

> Now that you mentioned it, that one in particular deserves more thought. There
> is a lot of code doing exactly the same and one QTranslator can only load one
> translation.

> So, first, we should probably add functions to QTranslator and/or
> QStandardPaths to find the translations so we don't have to deploy the looping.
> Second, we should investigate whether QTranslator should be able to keep
> multiple translation files: if we can have multiple translation files, can more
> than one of them contain content? And if so, are they additive or do they
> replace?

That sounds like a can of worms - but one we may need to look into.

>> Perhaps a naive
>>
>>     QString app = QLibraryInfo::paths(QLibraryInfo::BinariesPath).first();
>>
>> is fine, as long as paths() guarantees that there is always at least one
>> entry. But is it a practice we want to encourage?

Our examples are meant to showcase best practice.  I do not think
ignoring all but the first entry in a path-list is best practice.

> Same as above: it seems to me we want a locate() API like QStandardPaths.

That sounds a lot like QLocaleSelector [1] just got another argument
added to why we need it.

[1] https://qt-project.atlassian.net/browse/QTBUG-112765

	Eddy.