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

[Volker Hilsheimer]

On 26 Jul 2026, at 20:09, Thiago Macieira <thiago.macieira at intel.com> wrote:

In favour of QLibraryInfo::paths()
https://codereview.qt-project.org/c/qt/qtbase/+/744726

The correct thing to do is to deprecate, and force everyone who is using it to
adjust to having more than one path. In a lot of cases, it's already used in a
loop, so the fix is simple. In others, it's the right thing to do. And in the
rest, it documents in the code that you're taking the first and ignoring the
remainder, which is what path() does.

But it produces a lot of warnings in examples and tests.

Do we want this?


https://codereview.qt-project.org/c/qt/qtbase/+/560001 introduced paths() with https://qt-project.atlassian.net/browse/QTBUG-124009 "Support a way to easily set import paths for QML engine & tooling” as the rationale.

Beyond QmlImportPaths, are there any other practical uses for respecting multiple entries? QLibraryInfo was originally designed to provide information about the Qt libraries, and having e.g. multiple locations of the Qt library translations, binary, or libraries doesn’t seem useful; but I might be missing something.

And the number of non-Qt callers for paths(QLibraryInfo::QmlImportsPath) might be zero.

If there are no reasons, then requiring everyone to call paths(QLibraryInfo::XxxPath).first() (and feeling bad about potentially missing certain entries) seems suboptimal. Perhaps deprecating paths() and adding a dedicated QLibraryInfo::qmlImportPaths() would better reflect the actual use case?

Volker

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20260727/8362579b/attachment.htm>