Re: Review Request 115210: Always set DATA_INSTALL_DIR to %ALLUSERSPROFILE% on Windows
On Jan. 22, 2014, 8:22 a.m., Patrick von Reth wrote: Until now we had no problems with the data installed to bin/../share and this setup would make it impossible to have multiple independent kde setups on one system. Alexander Richardson wrote: I know. The problem is QStandardPaths with QStandardPaths::GenericDataLocation only looks in %ALLUSERSPROFILE% and I think %APPDATA%. KF5 based KDE software won't work otherwise since it can't find the data. I think the better way of fixing this is patching Qt, but for now this works. Patrick Spendrin wrote: Can you keep that patch locally for now and we try and come up with a patch for Qt instead? We cannot restrict ourselves at that point I think. Alexander Richardson wrote: Sure no problem. I'll drop this request David Faure wrote: So what do you recommend instead, for QStandardPaths? Checking some non-standard environment variable? or? Alexander Richardson wrote: I would go for the environment variable. Something like QSTANDARDPATHS_EXTRA_DATA_DIRS that is checked in addition to the default dirs. Would also be useful for other cases: e.g. in the okteta unit tests I set XDG_DATA_DIRS so that my test data gets found by QStandardPaths (I know there is QFINDTESTDATA, but that won't work in that case). It would also be nice if there were some cross-platform solution like QStandardpaths::addDirectory(QStandardPaths::StandardLocation, const QString path) to inject (like KStandardDirs::addResourceDir). Patrick von Reth wrote: I don't like the idea of using the env var as this would require the user to setup the variables or a kde process to set them up. We also would get an undefined behaviour if the env var is not set. I think kde is not the only qt project ported to windows wich uses the bin/../share location on windows, so why not only add this path with a low priority to QStrandardpathes? David Faure wrote: I agree that the env var would be quite inconvenient, which is why I was dubious about that approach. A method to add paths wouldn't help either (how would all apps do it?) bin/../share means go up one level from the location of the executable and enter share? I thought Windows apps didn't use a bin/ dir actually, but were rather in the toplevel? Anyhow I'd be fine with that, especially if you can find any documentation of this outside of kde (to explain the reasoning in the Qt change request). Andrius da Costa Ribas wrote: As far as I can see: 1 - Most GNU apps and libs ported from *nix to Windows use $PREFIX/bin, $PREFIX/share etc... and PREFIX is not standard on windows (those apps normally don't use %PROGRAMFILES%) * Other autoconf-based apps and libs also follow this structure * even those using %PROGRAMFILES% also follow this structure (e.g. for GIMP 2, $PREFIX is %PROGRAMFILES%\GIMP 2\, having bin, lib, share... inside it) 2 - Most CMake-based apps also follow a similar pattern, relative to $CMAKE_INSTALL_PREFIX, having no specific if(WIN32) to install to a different directory structure * Cmake itself is distributed in this kind of structure (http://www.cmake.org/files/v2.8/cmake-2.8.12.2.zip) I think those can explain the reasoning needed for a Qt request. David Faure wrote: Yes, a single monolithic can somehow find out about its own PREFIX (e.g. by writing it into the registry at install time, right? Or indeed from the path where the .exe is being started, simply). But the issue here is what if you install several apps (and possibly several frameworks), and they need to find each other's stuff... Andrius da Costa Ribas wrote: That's the exact same situation of using XDG_DATA_DIRS on *nix. For KDE-Windows we install all packages into the same prefix for a given KDE set up. We had these arguments already when thinking about how to install KDE on Windows, a thing where we do have almost all possible control. - One argument why this doesn't work is that there are multiple (incompatible) compilers on windows. Since e.g. plugins etc. are incompatible, you can either enforce one single compiler (that is virtually impossible for pure Qt applications, but it would be possible to some extend for KDE apps). - Since shared data is very likely also version dependent, you'll have to invent versioned folders (e.g. %ALLUSERSPROFILE%\kde-share-5.4.0-123deadbeef vs. %ALLUSERSPROFILE%\kde-share-5.4.0-123cafecafe). This actually moves the problem of finding compatible versions to another location and messes up ALLUSERSPROFILE. - What about security issues? If I install an application as a single user in a separate partition (so to hide it from cops... ;-)), you'd leave an unwanted trace in that case. Similar problems can occur with portable apps where you might not even have access to that
Re: Review Request 115210: Always set DATA_INSTALL_DIR to %ALLUSERSPROFILE% on Windows
On Jan. 22, 2014, 8:22 a.m., Patrick von Reth wrote: Until now we had no problems with the data installed to bin/../share and this setup would make it impossible to have multiple independent kde setups on one system. Alexander Richardson wrote: I know. The problem is QStandardPaths with QStandardPaths::GenericDataLocation only looks in %ALLUSERSPROFILE% and I think %APPDATA%. KF5 based KDE software won't work otherwise since it can't find the data. I think the better way of fixing this is patching Qt, but for now this works. Patrick Spendrin wrote: Can you keep that patch locally for now and we try and come up with a patch for Qt instead? We cannot restrict ourselves at that point I think. Alexander Richardson wrote: Sure no problem. I'll drop this request David Faure wrote: So what do you recommend instead, for QStandardPaths? Checking some non-standard environment variable? or? Alexander Richardson wrote: I would go for the environment variable. Something like QSTANDARDPATHS_EXTRA_DATA_DIRS that is checked in addition to the default dirs. Would also be useful for other cases: e.g. in the okteta unit tests I set XDG_DATA_DIRS so that my test data gets found by QStandardPaths (I know there is QFINDTESTDATA, but that won't work in that case). It would also be nice if there were some cross-platform solution like QStandardpaths::addDirectory(QStandardPaths::StandardLocation, const QString path) to inject (like KStandardDirs::addResourceDir). Patrick von Reth wrote: I don't like the idea of using the env var as this would require the user to setup the variables or a kde process to set them up. We also would get an undefined behaviour if the env var is not set. I think kde is not the only qt project ported to windows wich uses the bin/../share location on windows, so why not only add this path with a low priority to QStrandardpathes? David Faure wrote: I agree that the env var would be quite inconvenient, which is why I was dubious about that approach. A method to add paths wouldn't help either (how would all apps do it?) bin/../share means go up one level from the location of the executable and enter share? I thought Windows apps didn't use a bin/ dir actually, but were rather in the toplevel? Anyhow I'd be fine with that, especially if you can find any documentation of this outside of kde (to explain the reasoning in the Qt change request). Andrius da Costa Ribas wrote: As far as I can see: 1 - Most GNU apps and libs ported from *nix to Windows use $PREFIX/bin, $PREFIX/share etc... and PREFIX is not standard on windows (those apps normally don't use %PROGRAMFILES%) * Other autoconf-based apps and libs also follow this structure * even those using %PROGRAMFILES% also follow this structure (e.g. for GIMP 2, $PREFIX is %PROGRAMFILES%\GIMP 2\, having bin, lib, share... inside it) 2 - Most CMake-based apps also follow a similar pattern, relative to $CMAKE_INSTALL_PREFIX, having no specific if(WIN32) to install to a different directory structure * Cmake itself is distributed in this kind of structure (http://www.cmake.org/files/v2.8/cmake-2.8.12.2.zip) I think those can explain the reasoning needed for a Qt request. Yes, a single monolithic can somehow find out about its own PREFIX (e.g. by writing it into the registry at install time, right? Or indeed from the path where the .exe is being started, simply). But the issue here is what if you install several apps (and possibly several frameworks), and they need to find each other's stuff... - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115210/#review47983 --- On Jan. 22, 2014, 2:53 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115210/ --- (Updated Jan. 22, 2014, 2:53 p.m.) Review request for Build System, Extra Cmake Modules, KDE Frameworks, and kdewin. Repository: extra-cmake-modules Description --- Always set DATA_INSTALL_DIR to %ALLUSERSPROFILE% on Windows Otherwise QStandardPaths will always fail with e.g. GenericDataLocation Diffs - kde-modules/KDEInstallDirs.cmake 46e15c17d488d56f146aba0c2d420f74a22b9152 Diff: https://git.reviewboard.kde.org/r/115210/diff/ Testing --- Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115210: Always set DATA_INSTALL_DIR to %ALLUSERSPROFILE% on Windows
On Jan. 22, 2014, 8:22 a.m., Patrick von Reth wrote: Until now we had no problems with the data installed to bin/../share and this setup would make it impossible to have multiple independent kde setups on one system. Alexander Richardson wrote: I know. The problem is QStandardPaths with QStandardPaths::GenericDataLocation only looks in %ALLUSERSPROFILE% and I think %APPDATA%. KF5 based KDE software won't work otherwise since it can't find the data. I think the better way of fixing this is patching Qt, but for now this works. Patrick Spendrin wrote: Can you keep that patch locally for now and we try and come up with a patch for Qt instead? We cannot restrict ourselves at that point I think. Alexander Richardson wrote: Sure no problem. I'll drop this request David Faure wrote: So what do you recommend instead, for QStandardPaths? Checking some non-standard environment variable? or? Alexander Richardson wrote: I would go for the environment variable. Something like QSTANDARDPATHS_EXTRA_DATA_DIRS that is checked in addition to the default dirs. Would also be useful for other cases: e.g. in the okteta unit tests I set XDG_DATA_DIRS so that my test data gets found by QStandardPaths (I know there is QFINDTESTDATA, but that won't work in that case). It would also be nice if there were some cross-platform solution like QStandardpaths::addDirectory(QStandardPaths::StandardLocation, const QString path) to inject (like KStandardDirs::addResourceDir). Patrick von Reth wrote: I don't like the idea of using the env var as this would require the user to setup the variables or a kde process to set them up. We also would get an undefined behaviour if the env var is not set. I think kde is not the only qt project ported to windows wich uses the bin/../share location on windows, so why not only add this path with a low priority to QStrandardpathes? David Faure wrote: I agree that the env var would be quite inconvenient, which is why I was dubious about that approach. A method to add paths wouldn't help either (how would all apps do it?) bin/../share means go up one level from the location of the executable and enter share? I thought Windows apps didn't use a bin/ dir actually, but were rather in the toplevel? Anyhow I'd be fine with that, especially if you can find any documentation of this outside of kde (to explain the reasoning in the Qt change request). Andrius da Costa Ribas wrote: As far as I can see: 1 - Most GNU apps and libs ported from *nix to Windows use $PREFIX/bin, $PREFIX/share etc... and PREFIX is not standard on windows (those apps normally don't use %PROGRAMFILES%) * Other autoconf-based apps and libs also follow this structure * even those using %PROGRAMFILES% also follow this structure (e.g. for GIMP 2, $PREFIX is %PROGRAMFILES%\GIMP 2\, having bin, lib, share... inside it) 2 - Most CMake-based apps also follow a similar pattern, relative to $CMAKE_INSTALL_PREFIX, having no specific if(WIN32) to install to a different directory structure * Cmake itself is distributed in this kind of structure (http://www.cmake.org/files/v2.8/cmake-2.8.12.2.zip) I think those can explain the reasoning needed for a Qt request. David Faure wrote: Yes, a single monolithic can somehow find out about its own PREFIX (e.g. by writing it into the registry at install time, right? Or indeed from the path where the .exe is being started, simply). But the issue here is what if you install several apps (and possibly several frameworks), and they need to find each other's stuff... That's the exact same situation of using XDG_DATA_DIRS on *nix. For KDE-Windows we install all packages into the same prefix for a given KDE set up. - Andrius da Costa --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115210/#review47983 --- On Jan. 22, 2014, 2:53 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115210/ --- (Updated Jan. 22, 2014, 2:53 p.m.) Review request for Build System, Extra Cmake Modules, KDE Frameworks, and kdewin. Repository: extra-cmake-modules Description --- Always set DATA_INSTALL_DIR to %ALLUSERSPROFILE% on Windows Otherwise QStandardPaths will always fail with e.g. GenericDataLocation Diffs - kde-modules/KDEInstallDirs.cmake 46e15c17d488d56f146aba0c2d420f74a22b9152 Diff: https://git.reviewboard.kde.org/r/115210/diff/ Testing --- Thanks,
Re: Review Request 115210: Always set DATA_INSTALL_DIR to %ALLUSERSPROFILE% on Windows
On Jan. 22, 2014, 8:22 a.m., Patrick von Reth wrote: Until now we had no problems with the data installed to bin/../share and this setup would make it impossible to have multiple independent kde setups on one system. Alexander Richardson wrote: I know. The problem is QStandardPaths with QStandardPaths::GenericDataLocation only looks in %ALLUSERSPROFILE% and I think %APPDATA%. KF5 based KDE software won't work otherwise since it can't find the data. I think the better way of fixing this is patching Qt, but for now this works. Patrick Spendrin wrote: Can you keep that patch locally for now and we try and come up with a patch for Qt instead? We cannot restrict ourselves at that point I think. Alexander Richardson wrote: Sure no problem. I'll drop this request David Faure wrote: So what do you recommend instead, for QStandardPaths? Checking some non-standard environment variable? or? Alexander Richardson wrote: I would go for the environment variable. Something like QSTANDARDPATHS_EXTRA_DATA_DIRS that is checked in addition to the default dirs. Would also be useful for other cases: e.g. in the okteta unit tests I set XDG_DATA_DIRS so that my test data gets found by QStandardPaths (I know there is QFINDTESTDATA, but that won't work in that case). It would also be nice if there were some cross-platform solution like QStandardpaths::addDirectory(QStandardPaths::StandardLocation, const QString path) to inject (like KStandardDirs::addResourceDir). Patrick von Reth wrote: I don't like the idea of using the env var as this would require the user to setup the variables or a kde process to set them up. We also would get an undefined behaviour if the env var is not set. I think kde is not the only qt project ported to windows wich uses the bin/../share location on windows, so why not only add this path with a low priority to QStrandardpathes? David Faure wrote: I agree that the env var would be quite inconvenient, which is why I was dubious about that approach. A method to add paths wouldn't help either (how would all apps do it?) bin/../share means go up one level from the location of the executable and enter share? I thought Windows apps didn't use a bin/ dir actually, but were rather in the toplevel? Anyhow I'd be fine with that, especially if you can find any documentation of this outside of kde (to explain the reasoning in the Qt change request). As far as I can see: 1 - Most GNU apps and libs ported from *nix to Windows use $PREFIX/bin, $PREFIX/share etc... and PREFIX is not standard on windows (those apps normally don't use %PROGRAMFILES%) * Other autoconf-based apps and libs also follow this structure * even those using %PROGRAMFILES% also follow this structure (e.g. for GIMP 2, $PREFIX is %PROGRAMFILES%\GIMP 2\, having bin, lib, share... inside it) 2 - Most CMake-based apps also follow a similar pattern, relative to $CMAKE_INSTALL_PREFIX, having no specific if(WIN32) to install to a different directory structure * Cmake itself is distributed in this kind of structure (http://www.cmake.org/files/v2.8/cmake-2.8.12.2.zip) I think those can explain the reasoning needed for a Qt request. - Andrius da Costa --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115210/#review47983 --- On Jan. 22, 2014, 2:53 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115210/ --- (Updated Jan. 22, 2014, 2:53 p.m.) Review request for Build System, Extra Cmake Modules, KDE Frameworks, and kdewin. Repository: extra-cmake-modules Description --- Always set DATA_INSTALL_DIR to %ALLUSERSPROFILE% on Windows Otherwise QStandardPaths will always fail with e.g. GenericDataLocation Diffs - kde-modules/KDEInstallDirs.cmake 46e15c17d488d56f146aba0c2d420f74a22b9152 Diff: https://git.reviewboard.kde.org/r/115210/diff/ Testing --- Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115210: Always set DATA_INSTALL_DIR to %ALLUSERSPROFILE% on Windows
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115210/#review47983 --- Until now we had no problems with the data installed to bin/../share and this setup would make it impossible to have multiple independent kde setups on one system. - Patrick von Reth On Jan. 22, 2014, 1:56 a.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115210/ --- (Updated Jan. 22, 2014, 1:56 a.m.) Review request for Build System, Extra Cmake Modules, KDE Frameworks, and kdewin. Repository: extra-cmake-modules Description --- Always set DATA_INSTALL_DIR to %ALLUSERSPROFILE% on Windows Otherwise QStandardPaths will always fail with e.g. GenericDataLocation Diffs - kde-modules/KDEInstallDirs.cmake 46e15c17d488d56f146aba0c2d420f74a22b9152 Diff: https://git.reviewboard.kde.org/r/115210/diff/ Testing --- Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115210: Always set DATA_INSTALL_DIR to %ALLUSERSPROFILE% on Windows
On Jan. 22, 2014, 9:22 a.m., Patrick von Reth wrote: Until now we had no problems with the data installed to bin/../share and this setup would make it impossible to have multiple independent kde setups on one system. I know. The problem is QStandardPaths with QStandardPaths::GenericDataLocation only looks in %ALLUSERSPROFILE% and I think %APPDATA%. KF5 based KDE software won't work otherwise since it can't find the data. I think the better way of fixing this is patching Qt, but for now this works. - Alexander --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115210/#review47983 --- On Jan. 22, 2014, 2:56 a.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115210/ --- (Updated Jan. 22, 2014, 2:56 a.m.) Review request for Build System, Extra Cmake Modules, KDE Frameworks, and kdewin. Repository: extra-cmake-modules Description --- Always set DATA_INSTALL_DIR to %ALLUSERSPROFILE% on Windows Otherwise QStandardPaths will always fail with e.g. GenericDataLocation Diffs - kde-modules/KDEInstallDirs.cmake 46e15c17d488d56f146aba0c2d420f74a22b9152 Diff: https://git.reviewboard.kde.org/r/115210/diff/ Testing --- Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115210: Always set DATA_INSTALL_DIR to %ALLUSERSPROFILE% on Windows
On Jan. 22, 2014, 8:22 a.m., Patrick von Reth wrote: Until now we had no problems with the data installed to bin/../share and this setup would make it impossible to have multiple independent kde setups on one system. Alexander Richardson wrote: I know. The problem is QStandardPaths with QStandardPaths::GenericDataLocation only looks in %ALLUSERSPROFILE% and I think %APPDATA%. KF5 based KDE software won't work otherwise since it can't find the data. I think the better way of fixing this is patching Qt, but for now this works. Can you keep that patch locally for now and we try and come up with a patch for Qt instead? We cannot restrict ourselves at that point I think. - Patrick --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115210/#review47983 --- On Jan. 22, 2014, 1:56 a.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115210/ --- (Updated Jan. 22, 2014, 1:56 a.m.) Review request for Build System, Extra Cmake Modules, KDE Frameworks, and kdewin. Repository: extra-cmake-modules Description --- Always set DATA_INSTALL_DIR to %ALLUSERSPROFILE% on Windows Otherwise QStandardPaths will always fail with e.g. GenericDataLocation Diffs - kde-modules/KDEInstallDirs.cmake 46e15c17d488d56f146aba0c2d420f74a22b9152 Diff: https://git.reviewboard.kde.org/r/115210/diff/ Testing --- Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115210: Always set DATA_INSTALL_DIR to %ALLUSERSPROFILE% on Windows
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115210/ --- (Updated Jan. 22, 2014, 3:53 p.m.) Status -- This change has been discarded. Review request for Build System, Extra Cmake Modules, KDE Frameworks, and kdewin. Repository: extra-cmake-modules Description --- Always set DATA_INSTALL_DIR to %ALLUSERSPROFILE% on Windows Otherwise QStandardPaths will always fail with e.g. GenericDataLocation Diffs - kde-modules/KDEInstallDirs.cmake 46e15c17d488d56f146aba0c2d420f74a22b9152 Diff: https://git.reviewboard.kde.org/r/115210/diff/ Testing --- Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115210: Always set DATA_INSTALL_DIR to %ALLUSERSPROFILE% on Windows
On Jan. 22, 2014, 9:22 a.m., Patrick von Reth wrote: Until now we had no problems with the data installed to bin/../share and this setup would make it impossible to have multiple independent kde setups on one system. Alexander Richardson wrote: I know. The problem is QStandardPaths with QStandardPaths::GenericDataLocation only looks in %ALLUSERSPROFILE% and I think %APPDATA%. KF5 based KDE software won't work otherwise since it can't find the data. I think the better way of fixing this is patching Qt, but for now this works. Patrick Spendrin wrote: Can you keep that patch locally for now and we try and come up with a patch for Qt instead? We cannot restrict ourselves at that point I think. Sure no problem. I'll drop this request - Alexander --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115210/#review47983 --- On Jan. 22, 2014, 3:53 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115210/ --- (Updated Jan. 22, 2014, 3:53 p.m.) Review request for Build System, Extra Cmake Modules, KDE Frameworks, and kdewin. Repository: extra-cmake-modules Description --- Always set DATA_INSTALL_DIR to %ALLUSERSPROFILE% on Windows Otherwise QStandardPaths will always fail with e.g. GenericDataLocation Diffs - kde-modules/KDEInstallDirs.cmake 46e15c17d488d56f146aba0c2d420f74a22b9152 Diff: https://git.reviewboard.kde.org/r/115210/diff/ Testing --- Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115210: Always set DATA_INSTALL_DIR to %ALLUSERSPROFILE% on Windows
On Jan. 22, 2014, 8:22 a.m., Patrick von Reth wrote: Until now we had no problems with the data installed to bin/../share and this setup would make it impossible to have multiple independent kde setups on one system. Alexander Richardson wrote: I know. The problem is QStandardPaths with QStandardPaths::GenericDataLocation only looks in %ALLUSERSPROFILE% and I think %APPDATA%. KF5 based KDE software won't work otherwise since it can't find the data. I think the better way of fixing this is patching Qt, but for now this works. Patrick Spendrin wrote: Can you keep that patch locally for now and we try and come up with a patch for Qt instead? We cannot restrict ourselves at that point I think. Alexander Richardson wrote: Sure no problem. I'll drop this request So what do you recommend instead, for QStandardPaths? Checking some non-standard environment variable? or? - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115210/#review47983 --- On Jan. 22, 2014, 2:53 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115210/ --- (Updated Jan. 22, 2014, 2:53 p.m.) Review request for Build System, Extra Cmake Modules, KDE Frameworks, and kdewin. Repository: extra-cmake-modules Description --- Always set DATA_INSTALL_DIR to %ALLUSERSPROFILE% on Windows Otherwise QStandardPaths will always fail with e.g. GenericDataLocation Diffs - kde-modules/KDEInstallDirs.cmake 46e15c17d488d56f146aba0c2d420f74a22b9152 Diff: https://git.reviewboard.kde.org/r/115210/diff/ Testing --- Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115210: Always set DATA_INSTALL_DIR to %ALLUSERSPROFILE% on Windows
On Jan. 22, 2014, 8:22 a.m., Patrick von Reth wrote: Until now we had no problems with the data installed to bin/../share and this setup would make it impossible to have multiple independent kde setups on one system. Alexander Richardson wrote: I know. The problem is QStandardPaths with QStandardPaths::GenericDataLocation only looks in %ALLUSERSPROFILE% and I think %APPDATA%. KF5 based KDE software won't work otherwise since it can't find the data. I think the better way of fixing this is patching Qt, but for now this works. Patrick Spendrin wrote: Can you keep that patch locally for now and we try and come up with a patch for Qt instead? We cannot restrict ourselves at that point I think. Alexander Richardson wrote: Sure no problem. I'll drop this request David Faure wrote: So what do you recommend instead, for QStandardPaths? Checking some non-standard environment variable? or? Alexander Richardson wrote: I would go for the environment variable. Something like QSTANDARDPATHS_EXTRA_DATA_DIRS that is checked in addition to the default dirs. Would also be useful for other cases: e.g. in the okteta unit tests I set XDG_DATA_DIRS so that my test data gets found by QStandardPaths (I know there is QFINDTESTDATA, but that won't work in that case). It would also be nice if there were some cross-platform solution like QStandardpaths::addDirectory(QStandardPaths::StandardLocation, const QString path) to inject (like KStandardDirs::addResourceDir). I don't like the idea of using the env var as this would require the user to setup the variables or a kde process to set them up. We also would get an undefined behaviour if the env var is not set. I think kde is not the only qt project ported to windows wich uses the bin/../share location on windows, so why not only add this path with a low priority to QStrandardpathes? - Patrick --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115210/#review47983 --- On Jan. 22, 2014, 2:53 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115210/ --- (Updated Jan. 22, 2014, 2:53 p.m.) Review request for Build System, Extra Cmake Modules, KDE Frameworks, and kdewin. Repository: extra-cmake-modules Description --- Always set DATA_INSTALL_DIR to %ALLUSERSPROFILE% on Windows Otherwise QStandardPaths will always fail with e.g. GenericDataLocation Diffs - kde-modules/KDEInstallDirs.cmake 46e15c17d488d56f146aba0c2d420f74a22b9152 Diff: https://git.reviewboard.kde.org/r/115210/diff/ Testing --- Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115210: Always set DATA_INSTALL_DIR to %ALLUSERSPROFILE% on Windows
On Jan. 22, 2014, 8:22 a.m., Patrick von Reth wrote: Until now we had no problems with the data installed to bin/../share and this setup would make it impossible to have multiple independent kde setups on one system. Alexander Richardson wrote: I know. The problem is QStandardPaths with QStandardPaths::GenericDataLocation only looks in %ALLUSERSPROFILE% and I think %APPDATA%. KF5 based KDE software won't work otherwise since it can't find the data. I think the better way of fixing this is patching Qt, but for now this works. Patrick Spendrin wrote: Can you keep that patch locally for now and we try and come up with a patch for Qt instead? We cannot restrict ourselves at that point I think. Alexander Richardson wrote: Sure no problem. I'll drop this request David Faure wrote: So what do you recommend instead, for QStandardPaths? Checking some non-standard environment variable? or? Alexander Richardson wrote: I would go for the environment variable. Something like QSTANDARDPATHS_EXTRA_DATA_DIRS that is checked in addition to the default dirs. Would also be useful for other cases: e.g. in the okteta unit tests I set XDG_DATA_DIRS so that my test data gets found by QStandardPaths (I know there is QFINDTESTDATA, but that won't work in that case). It would also be nice if there were some cross-platform solution like QStandardpaths::addDirectory(QStandardPaths::StandardLocation, const QString path) to inject (like KStandardDirs::addResourceDir). Patrick von Reth wrote: I don't like the idea of using the env var as this would require the user to setup the variables or a kde process to set them up. We also would get an undefined behaviour if the env var is not set. I think kde is not the only qt project ported to windows wich uses the bin/../share location on windows, so why not only add this path with a low priority to QStrandardpathes? I agree that the env var would be quite inconvenient, which is why I was dubious about that approach. A method to add paths wouldn't help either (how would all apps do it?) bin/../share means go up one level from the location of the executable and enter share? I thought Windows apps didn't use a bin/ dir actually, but were rather in the toplevel? Anyhow I'd be fine with that, especially if you can find any documentation of this outside of kde (to explain the reasoning in the Qt change request). - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115210/#review47983 --- On Jan. 22, 2014, 2:53 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115210/ --- (Updated Jan. 22, 2014, 2:53 p.m.) Review request for Build System, Extra Cmake Modules, KDE Frameworks, and kdewin. Repository: extra-cmake-modules Description --- Always set DATA_INSTALL_DIR to %ALLUSERSPROFILE% on Windows Otherwise QStandardPaths will always fail with e.g. GenericDataLocation Diffs - kde-modules/KDEInstallDirs.cmake 46e15c17d488d56f146aba0c2d420f74a22b9152 Diff: https://git.reviewboard.kde.org/r/115210/diff/ Testing --- Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115210: Always set DATA_INSTALL_DIR to %ALLUSERSPROFILE% on Windows
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115210/ --- (Updated Jan. 22, 2014, 2:56 a.m.) Review request for Build System, Extra Cmake Modules, KDE Frameworks, and kdewin. Repository: extra-cmake-modules Description --- Always set DATA_INSTALL_DIR to %ALLUSERSPROFILE% on Windows Otherwise QStandardPaths will always fail with e.g. GenericDataLocation Diffs - kde-modules/KDEInstallDirs.cmake 46e15c17d488d56f146aba0c2d420f74a22b9152 Diff: https://git.reviewboard.kde.org/r/115210/diff/ Testing --- Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
