> 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, > > Alexander Richardson > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
