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

[David Redondo]

Am Montag, 27. Juli 2026, 13:21 schrieb Fabian Kosmale via Development:
> Hi,
> 
> besides the Apple use case Tor Arne listed, I believe we have seen similar requirements for Harmony OS, and you also run into interesting issues with NixOS if I recall correctly (though the latter is at least not officially supported).
> Qt itself should definitely not use the singular form; I'm not quite sure how much usage the API sees in user applications.

Hi, 

I checked an in KDE we seem to have some but not a lot of usage.
https://lxr.kde.org/search?%21v=kf6-qt6&_filestring=&_string=QLibraryInfo%3A%3Apath

Cheers,
David

> In any case, if we deprecate the singe item API, we should however provide some more guidance than just "us paths".
> 
> Fabian
> 
> --
> Fabian Kosmale
> Manager
> 
> The Qt Company GmbH
> Erich-Thilo-Str. 10
> D-12489 Berlin
> fabian.kosmale at qt.io
> +49 1638686070
> http://qt.io<http://qt.io/>
> 
> Geschäftsführer: Mika Pälsi, Juha Varelius, Juha Puputti
> Sitz der Gesellschaft: Berlin
> Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
> --
> 
> Confidential
> ________________________________
> Von: Development <development-bounces at qt-project.org> im Auftrag von Tor Arne Vestbø via Development <development at qt-project.org>
> Gesendet: Montag, 27. Juli 2026 13:13
> An: Volker Hilsheimer <volker.hilsheimer at qt.io>
> Cc: Macieira, Thiago <thiago.macieira at intel.com>; development at qt-project.org <development at qt-project.org>
> Betreff: Re: [Development] QLibraryInfo::path(): to deprecate or not to deprecate?
> 
> 
> 
> On 27 Jul 2026, at 10:46, Volker Hilsheimer via Development <development at qt-project.org> wrote:
> 
> 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?
> 
> Yes, see series of patches under this topic: https://codereview.qt-project.org/q/topic:%22qlibraryinfo%22
> 
> tl;dr, plugins and other artifacts covered by QLibraryInfo might live both in the installed Qt and the app bundle on Apple platforms during development. And when deployed (into a single app bundle) there might be several paths inside that bundle we want to look for plugins and other artifacts.
> 
> 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.
> 
> That was the original design, based on the premise that Qt lives in a prefix-installed system location. Today with reloactable Qt we’ve moved away from the original design, so it’s more of a “where should I look for things Qt needs”.
> 
> Tor Arne
> 
>