Re: [Development] QStandardPaths could be helpful for cross platform portability, Qt Everywhere
Tor Arne, As a test I modified my setup on OS X yesterday to pass -DCMAKE_INSTALL_DATADIR="/Users/jeremy/Library/Application Support/" to every KDE module's cmake comand. This successfully installed all supporting data files into ~/Library/Application Support/foo and only required a couple of minor changes to KF5FooConfig.cmake files so these data files (mostly scripts, but also the previously mentioned xsl data files) could be found when building other libraries or applications that depend on foo. So far everything "just works" as it did with the QSP patch. I.e. stuff that's broken on OS X is still broken, but those are other issues. I'll write up a suggestion on the KDE mailing lists today about how best to make these changes OS X specific whether that be having separate FooConfig.cmake.in files for OS X or by changing them to be more cross platform anyway, we'll see. BR, Jeremy On Wed, Feb 25, 2015 at 4:51 AM, Tor Arne Vestbø wrote: > On 25/02/15 12:31, Tor Arne Vestbø wrote: > >> This should be fixed for OS X (and iOS). ~/Library/Application Support >> can be used for installed application data, but is most typically used >> for generated application data that is not directly user documents >> (which should live in ~/Documents), so the app bundle should be one of >> the paths returned by QStandardPaths. >> > > And looking at the QSP docs, this should already be the case: > > "~/Library/Application Support/", "/Library/Application > Support/". "/../Resources" > > tor arne > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QStandardPaths could be helpful for cross platform portability, Qt Everywhere
On 25/02/15 12:31, Tor Arne Vestbø wrote: > This should be fixed for OS X (and iOS). ~/Library/Application Support > can be used for installed application data, but is most typically used > for generated application data that is not directly user documents > (which should live in ~/Documents), so the app bundle should be one of > the paths returned by QStandardPaths. And looking at the QSP docs, this should already be the case: "~/Library/Application Support/", "/Library/Application Support/". "/../Resources" tor arne ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QStandardPaths could be helpful for cross platform portability, Qt Everywhere
On 25/02/15 01:04, Thiago Macieira wrote: > On Wednesday 25 February 2015 00:44:49 Kevin Kofler wrote: >> Still, I don't understand the strong resistance to implementing this. >> Supporting XDG_* everywhere helps portability and does not hurt the >> non-freedesktop.org platforms in any way. If the user doesn't use those >> environment variables, then nothing changes at all. > > The resistance is understanding why it's needed. Exactly. > First and foremost, as Jeremy said, QSP is lacking functionality even for the > standard way of doing things on those OS. Which are fixes to QSP's implementation on those platforms, and doesn't require new APIs or hooks/backdoors. > Second, there's also the question of unmodified Unix libraries and shared, > global resources. Given this latter argument, I think we will have to > implement the XDG variables. I'd like to see these unmodified Unix libraries and shared resources, and in which case having XDG variables helps. For non-framework libraries perhaps an extensions to QLibraryInfo that lets the library figure out its own install prefix is more appropriate. We also already have a cross platform solution for library resources: QRC, so some of these use-cases may be better supported by that. tor arne ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QStandardPaths could be helpful for cross platform portability, Qt Everywhere
Thanks for the write up Jeremy, On 24/02/15 07:24, Jeremy Whiting wrote: > QStandardPaths is useful to give paths to various places that are common > to all platforms. ConfigLocation tells where configurations should be > stored or read from, GenericDataLocation is where data should be, > AppDataLocation is where application specific location should be, etc. > This works fairly well except where assumptions are made as to where > data, configurations, applications, etc. are installed based on one > platform. For example applications written with Linux as a target can > assume that GenericDataLocation will include /usr/share/ and that > ConfigLocation will include ~/.config, then expect those to "just work" > when the code is built on other platforms. Just to clarify, as the wording of this paragraph was a bit funky: any assumption about what QStandardPaths returns is bound to fail when targeting multiple platforms, so "applications written with Linux as a target" can and should _not_ assume anything about the paths, and will fail on non Linux platforms if they do. I think that's what you're saying as well, I just read it a bit weird the first time around :) > One possible solution to this for app bundles on OS X is to include the > data files any application needs inside the .app itself. The problem > with that is that QStandardPaths doesn't look for files inside the .app > bundle so if we included icons, data files, etc. in addition to > libraries and application icon resources the library code that uses > QStandardPaths unmodified to find these files would still fail. The same > argument could be used for relative paths on Windows. This should be fixed for OS X (and iOS). ~/Library/Application Support can be used for installed application data, but is most typically used for generated application data that is not directly user documents (which should live in ~/Documents), so the app bundle should be one of the paths returned by QStandardPaths. > One use case for the above problem are applications that use data files > from their own project and also files from other projects. kdoctools > meinproc5 executable is one use case. It uses QStandardPaths to locate > the xsl stylesheets required to create documentation. These stylesheets > come from kdoctools and also kdelibs4support. These two separate > projects could be modified to put their files into /Library/Application > Support on OS X so QStandardPaths can find them. This is a tool used by > developers, not end users, so installing here shouldn't be a problem. This is the correct approach. Cross platform deployment (installing files into /usr/share on Linux and ~/Library/Application Support on OS X) + cross platform runtime lookup through QStandardPaths. Qt is lacking on providing the former, but that doesn't mean it's not the right approach. > Another use case are data files used by multiple applications. These are > stored and safely looked up via QStandardPaths on Linux/Unix in > /usr/share followed by some application or data type prefix and the data > files themselves. The OS X equivalent is to install the shared data files into ~/Library/Application Support/ and look them up using QStandardPaths::GenericDataLocation. > > Proposed and considered solutions: None of these seem needed if you install the data to the right location on the given platform? > Obviously some changes will be required to any software that has made > the above mentioned assumptions about QStandardPaths build systems Yes. > if we could also improve QStandardPaths itself in one of the above > mentioned solutions that could possibly help make it easier to port > applications and libraries from one of Qt's platforms to another. We should put effort into improving how Qt helps out with the cross platform deployment/installation phase, not into assuming the deployment is the same on all platforms and working around it in the runtime lookup phase. Tor Arne ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QStandardPaths could be helpful for cross platform portability, Qt Everywhere
On Wednesday 25 February 2015 00:44:49 Kevin Kofler wrote: > Jeremy Whiting wrote: > > One solution is to use/support XDG_*_DIRS environment variables on all > > platforms. This has one advantage in that the same tools can be used on > > all platforms to customize the paths given by the standard. This is ok for > > developers working on software, but not the best idea for shipping actual > > software to end users since setting environment variables is not often > > easy or advisable and has other effects. Note this is the approach of the > > patch in gerrit, but it's a non-solution because of the above mentioned > > issues. > > Still, I don't understand the strong resistance to implementing this. > Supporting XDG_* everywhere helps portability and does not hurt the > non-freedesktop.org platforms in any way. If the user doesn't use those > environment variables, then nothing changes at all. The resistance is understanding why it's needed. Other platforms haven't needed this, so we have to answer the question of why we need to add it. People are asking: shouldn't apps and libs instead adapt to the OS in question? First and foremost, as Jeremy said, QSP is lacking functionality even for the standard way of doing things on those OS. Second, there's also the question of unmodified Unix libraries and shared, global resources. Given this latter argument, I think we will have to implement the XDG variables. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QStandardPaths could be helpful for cross platform portability, Qt Everywhere
Jeremy Whiting wrote: > One solution is to use/support XDG_*_DIRS environment variables on all > platforms. This has one advantage in that the same tools can be used on > all platforms to customize the paths given by the standard. This is ok for > developers working on software, but not the best idea for shipping actual > software to end users since setting environment variables is not often > easy or advisable and has other effects. Note this is the approach of the > patch in gerrit, but it's a non-solution because of the above mentioned > issues. Still, I don't understand the strong resistance to implementing this. Supporting XDG_* everywhere helps portability and does not hurt the non-freedesktop.org platforms in any way. If the user doesn't use those environment variables, then nothing changes at all. Kevin Kofler ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QStandardPaths could be helpful for cross platform portability, Qt Everywhere
On Monday 23 February 2015 23:24:07 Jeremy Whiting wrote: > A second solution is to add some API to QStandardPaths to modify the paths > at run time. This would allow libraries to add paths to QStandardPaths' > standard paths that it needs in its initialization methods. For example a > library that requires data files that it knows are installed to /some/path > can add /some/path to the GenericDataLocation via something like > QStandardPaths::addCustomPath(GenericDataLocation, "/some/path") and it's > subsequent calls to QStandardPaths::locate(GenericDataLocation, > "somedatafile") would get the file required. Hi Jeremy Thanks for the write up, it's appreciated. I'm wondering if the above should be a global config or if we should make QStandardPaths support creating an object that a library could use internally. If we choose the latter, a library could set up its own, private search paths and not bother anyone else. > Another similar option would be to always add relative paths based on the > application binary or library (or both) so libraries installed inside a > .app bundle on OS X could find the data files that are also inside the .app > bundle. This way binaries on Windows could also find data files and > libraries relative to the installation path of the executable itself, so if > end users install MyProgram into D:\Some\Path\Myprogram, and the installer > puts the data files beneath that, QStandardPaths api could find the data > files wanted. Indeed, we need that. For Qt itself, we have QLibraryInfo, but the installation prefix is usually hardcoded. For Mac, Linux and Windows, I think we have good solutions for determining the installation path of a library given a pointer located inside it, so we should really investigate relocatable builds and adapt both QLibraryInfo and QStandardPaths. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QStandardPaths could be helpful for cross platform portability, Qt Everywhere
On Tuesday 24 February 2015 13:47:53 Sorvig Morten wrote: > On OS X (and iOS): place the resources in he framework bundle for the > component that owns them. Add public API to the component for accessing the > resources. Agreed. That means libraries that get installed as frameworks should simply carry their private data inside their bundle. That makes it a lot easier to move, remove, and update the framework. > Installers and deployment utilities can then move the framework bundles as > needed, for example to a shared location for a “system” installation, or to > the applicaiton bundle to create a stand-alone, sandboxable app. Yep. However, I don't think that's sufficient. It misses two important use-cases: 1) non-framework libraries 2) libraries (framework or not) accessing global resources installed by global package management Both cases still require finding unbundled data. > Thanks for the writeup! I find sharing the "big picture" like this very > useful. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QStandardPaths could be helpful for cross platform portability, Qt Everywhere
> On 24 Feb 2015, at 07:24, Jeremy Whiting wrote: > > Hello list, > > I discussed a bit with Thiago and some others on irc this evening and have > realized that the QStandardPaths patch from [1] and discussion on [2] is > trying to solve too many problems at once. I'll list the problems here and > some possible solutions to these problems afterwards so we can discuss what > are appropriate/purposeful fixes to the problems and get these issues fixed. > > Thoughts, opinions, counterarguments, suggestions? (Disclaimer: I know little about KDE frameworks internals) On OS X (and iOS): place the resources in he framework bundle for the component that owns them. Add public API to the component for accessing the resources. Installers and deployment utilities can then move the framework bundles as needed, for example to a shared location for a “system” installation, or to the applicaiton bundle to create a stand-alone, sandboxable app. Thanks for the writeup! I find sharing the "big picture" like this very useful. Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
