Add path shortcuts for common user-space paths
What is the problem or limitation you are having?
Toga has a paths module that provides an anchor point for paths in the app, and for common "sandbox" locations such as config, data, and logs.
However, there's no anchor for common "user space" locations, such as "Documents", "Pictures" or "Desktop". These are all locations that an app may want to use; and are cross platform (on desktop, anyway).
Describe the solution you'd like
paths.desktop, paths.pictures, and paths.desktop should all return appropriate user-specific file system anchors.
Describe alternatives you've considered
We could pass responsibility for this off to platformdirs, as it provides analogous functionality.
Additional context
- On Linux, the FreeDesktop specification defines "known locations". The implementation provided by platformdirs could be used to inform what directories should be used, even if we don't actually use
platformdirsin the implementation. - On macOS, permissions are often required to access Desktop, Documents etc; we should check if those permissions are requested automatically on first access, or if an explicit permission check is required.
- On iOS (and Android?), there's probably not a folder that can be used for these paths. If there's no viable path, a platform should raise an exception.
For the existing directories in Toga's App.paths, the advantages over platformdirs are:
- Mobile support
- Saving the code from needing to specify its own app and developer name
But neither of these are applicable to desktop-only, non-app-specific directories. So why duplicate platformdirs and give ourselves more work?
The only possible advantage I can see is integration with the permissions mechanism on macOS. But is this actually the same mechanism as the camera or location permission, which require custom code in the app? Or is it something that happens transparently when the app accesses the directory for the first time?
For the existing directories in Toga's App.paths, the advantages over platformdirs are:
- Mobile support
There's actually already Android support in Platformdirs; although some of the path selections have interesting discrepancies between what Toga generates, ranging from arbitrary (using files instead of data as a user data suffix) to the... interesting (e.g, they don't use context.getCacheDir() as a base for user_cache_dir).
The implementation seems to be tied to Python4Android and Pyjnius, which would obviously be problematic; we'd likely have to split that backend into three to provide a third import option for Chaquopy.
I would assume they'd be amenable to an PR implementing iOS support as well, especially given the now official status of iOS as a platform. Any iOS backend would necessarily be Rubicon-specific, though, which implies there'd be a need for PyObjUs backend as well.
- Saving the code from needing to specify its own app and developer name
For me, this is the major reason that it makes sense for Toga to have this as a native API. It might be worth exploring using Platformdirs as the underlying implementation of Toga's API - there would be an unfortunate backwards incompatibility as we migrated, though.
The other benefit is that app.paths has app and toga paths, for which there's no analog in Platformdirs.
Ultimately, my thought is that while it is duplicated code, it's not complicated code. It's a definition of half a dozen paths, which are essentially all static definitions. We'd easily spend more time and effort discussing the process of migrating to Platformdirs than we would re-implementing these extra features.
The one thing that might convince me otherwise is the discussion on tox-dev/platformdirs#265, suggesting this should be in the Python standard library. That seems like a lot more productive as a path forward for this.
I wasn't suggesting entirely replacing App.paths with platformdirs, I was only talking about the new paths proposed by this issue, for which the two advantages I mentioned don't apply. It's not that difficult to explain to the developer that App.paths is only for app-specific paths, and non-app-specific paths should be obtained using platformdirs.
Granted - it's not too hard to explain the difference... but why make a difference at all? And why put ourselves in an explanation where we have to explain why we don't use platformdirs().user_data_path (et al)? The implementation of documents, pictures, and desktop is so trivial as to barely be worth worrying about, and then Toga has a single, consistent API for satisfying all paths.