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. 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 [email protected] +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 <[email protected]> im Auftrag von Tor Arne Vestbø via Development <[email protected]> Gesendet: Montag, 27. Juli 2026 13:13 An: Volker Hilsheimer <[email protected]> Cc: Macieira, Thiago <[email protected]>; [email protected] <[email protected]> Betreff: Re: [Development] QLibraryInfo::path(): to deprecate or not to deprecate? On 27 Jul 2026, at 10:46, Volker Hilsheimer via Development <[email protected]> wrote: On 26 Jul 2026, at 20:09, Thiago Macieira <[email protected]> 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
-- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
