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 > [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
