> 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

Reply via email to