@dfaure: You have shown interest in getting the data locations stuff fixed, still interested?

Adding Frederik CC.
I think it is really sad that we still can't use vanilla Qt to compile our stuff, perhaps we can get some in Qt Company traction for this.
We really just miss the last few meters to have some more consistent developer story.

I think we shall revisist

https://phabricator.kde.org/D2545

if that makes the Qt dbus patch not needed.

For the standard paths: perhaps I read the patches wrong, but at the moment we only patch this for macOS but we would like to have some similar behavior for Windows, too? Is that right @vonreth?

My current attempt to make QStandardPaths more flexible on Mac/Windows is https://codereview.qt-project.org/c/qt/qtbase/+/239952 ($QT_DATA_DIRS)
Please comment there whether this is actually what you need.

Thanks for linking that ;=)
From a first glance, that looks like what we want, but I think Hannah can better comment on this.

@vonreth : could we use the patch from the review request https://codereview.qt-project.org/c/qt/qtbase/+/239952 in craft to check if it does what we want?

I don't quite understand the whole data location situation. Are the KDE apps doing something completely non-standard? Maybe it's worthwhile to question KDE's approach at this point, since there seems to be no agreement on that it could possibly viable for mac/win from the Qt people. See comments on https://codereview.qt-project.org/c/qt/qtbase/+/239952

The most pressing issue exists on mac, Qt does not look for data in the install prefix but only in the bundle location.
So there is no way to run KDE applications in a dev environment without fully deploying them...

So how about putting the data into either the bundle location or in Library/Application Support/KDE or some other shared common place?
From the Qt perspective, we want to play by the platforms rules. And the task seems to be very much stuck, so it's maybe worthwhile to re-think if KDE cannot better accommodate the various platforms. QStandardPaths::GenericDataLocation sounds great for shared data.

To move the discussion forward, please clearly formulate the use case, I still don't understand the goal that you're trying to achieve myself.
Note that Qt is not trying to make your life miserable, we want to work together, but that only works if we understand the use case.

I think the issue is as following (Hannah can correct me if I am wrong)

1. We have some data that shall be shared between different applications and therefore uses QStandardPaths::GenericDataLocation for lookup. (e.g. mime-data, service files, ....)

2. If you really install the stuff in the system-wide global directory for that, e.g. "~/Library/Application Support", "/Library/Application Support" on macOS (see QStandardPaths::GenericDataLocation docs), all is fine.

3. During development, you normally can't do that, you install into some local prefix (otherwise you e.g. can't compile two different things as the same user)

4. On e.g. Windows, that works, as there QStandardPaths::GenericDataLocation expands to some "local" directory, too, see docs ("C:/Users/<USER>/AppData/Local", "C:/ProgramData", "<APPDIR>", "<APPDIR>/data"), on macOS you will fail, as only the above two user-globa things are queried

As the KDE applications are installed in a bundled they don't share a common prefix like <APPDIR>.

Also for Windows and Mac, unit tests are not executed in the installation directory, so <APPDIR> will for unit tests never point to the shared data dir.

In T11753#202324, @vonreth wrote:

The most pressing issue exists on mac, Qt does not look for data in the install prefix but only in the bundle location.

Can you clarify what you mean by this? AFAIK the QStandardPath locations for shared resources do not point into the app bundle but to one of the various Library/Application Support directories, or to ~/Library/Preferences (or to /Applications which it really shouldn't).

About that latter aspect: when I was first writing my MacPorts Portfiles for the KF5 Frameworks I almost had a unittest clear out my entire /Applications folder because QSP didn't have a testing version of the APPLICATIONS_LOCATION (still doesn't, I think).

Also: see https://phabricator.kde.org/T10112

See my comment above.
I think the only thing I messed up to describe is that the Windows behavior to look stuff up in the APPDIR local stuff isn't good enough for some shared data.

Therefore, corrected summary/use-case

1. We have some data that shall be shared between different applications and therefore uses QStandardPaths::GenericDataLocation for lookup. (e.g. mime-data, service files, ....)

2. If you really install the stuff in the system-wide global directory for that, e.g. "~/Library/Application Support", "/Library/Application Support" on macOS (see QStandardPaths::GenericDataLocation docs), all is fine, same for Windows.

3. During development, you normally can't do that, you install into some local prefix (otherwise you e.g. can't compile two different things as the same user).

4. If one has a possibility like with the QT_DATA_DIRS to redirect the search via QStandardPaths, part 3) will work and for normal deployment, nothing will change.

Is this more understandable?

On Unices, we normally never had issues with 3) as one can just use XDG_DATA_DIRS to redirect the access.

I originally tried to make the qt5 version installed by homebrew usable for KDE frameworks (e.g. find syntax files etc.) Currently you have to manually create symlinks in $HOME to /use/local/ to allow applications to find stuff. See https://github.com/KDE-mac/homebrew-kde/blob/master/tools/do-caveats.sh

The problem is that homebrew is not allowed to write to the home dir since the build and install runs in a sandbox that only allows access to the homebrew install prefix.
My attempt at fixing this was
https://codereview.qt-project.org/c/qt/qtbase/+/238640/ but that's also blocked.
It's not great since it hardcodes one path in the binary so it's not relocatable. Maybe if we had some mechanism to find data dirs relative to the qtbase library?

This is a different use case from the unit tests but also kinda interesting.