Re: Questions
refer to either the applications themselves or their stored data, and saved game data typically isn’t shared with other applications, so Games are kind of the perfect use case for sandboxed per-application data folders. For the purpose of making per-application data more accessible to end users, I opened several related issues suggesting an extension to GVFS for that purpose: https://gitlab.gnome.org/GNOME/gvfs/-/issues/547 https://github.com/flatpak/flatpak/issues/4173 But implementing this is beyond my ability, and it doesn’t seem to be a priority for the GVFS maintainers. What other thoughts do you have? Best, Elsie Hupp On Nov 22, 2021, at 2:28 AM, BARDOT Jérôme wrote: Thx Yes it is (helpfull). I already know some stuff i just need to make stuff i need works. :) I first come here for some data approch too. Do you think about more data like ebooks that can be great to have ? where each application basically just has its own sandboxed home folder => most stupid thing in the world We need an appropriate data security policies tool with an real identity manager. And i currently try to working on a such tool. If people here have ideas feel free to share. J. On 20/11/2021 20:15, Elsie Hupp wrote: Hi Jérôme, The Arch Wiki has a pretty good guide to the `xdg-user-dirs` package installed on most Linux distributions: https://wiki.archlinux.org/title/XDG_user_directories I’ve dug around in the boilerplate code for *looking up* `xdg-user-dirs`, and it basically queries `XDG_FOOBAR_DIR` for `FOOBAR`, so you *should* basically be able to define any custom folder you want. You can check out my pending pull request on `pyxdg` for a version of the code that’s somewhat easier to read than the original C: https://gitlab.freedesktop.org/xdg/pyxdg/-/merge_requests/13 The actual Python file: https://gitlab.freedesktop.org/xdg/pyxdg/-/blob/8fa45fbbe4cd6676b388ca0549f875739301ed21/xdg/UserDirectory.py Note that this is a simplified line-by-line translation of `xdg-user-dir-lookup`: https://gitlab.freedesktop.org/xdg/xdg-user-dirs/-/blob/master/xdg-user-dir-lookup.c However, a big part of the functionality behind `xdg-user-dirs` is (a) the basic list is standardized across most Linux distros, and (b) the actual name of the directory is localized into a large number of natural languages. The main reason actually that I joined this mailing list was to ask about directories for difficult-to-categorize use cases, like ebooks or podcasts (or code repositories or, yes, games). So, hypothetically, yes, you could define your own `xdg-user-dirs`. However, `xdg-user-dirs` is a tool rather than standard, and even if you got a pull request approved for some additional directory, it would probably take years to percolate out through the install base and never actually reach 100% of users. Oh, and you’d also need to get it adopted by both GLib and Qt. (Qt would probably be easier, considering Windows does IIRC have a `My Games` directory, so there’s already a cross-platform precedent.) This is to say that if you define your own custom directories in `xdg-user-dirs` in application code, you should always define a fallback. And in some respects `xdg-user-dirs` is kind of falling out of fashion with the rise in Flatpak and Snap for end-user applications, where each application basically just has its own sandboxed home folder, rather than using a shared per-content-type directory, even though Flatpak portals do increasingly support arbitrary locations in userspace. Anyway, I hope this is helpful! Best, Elsie Hupp On Nov 19, 2021, at 3:51 PM, Jérôme Bardot wrote: Hello, There is a way to to add this own stuff in XDG_CONFIG_HOME/user-dirs.dirs ? I want a XDG_GAMES_DIR= Also can i access to XDG var from a shell ? thx More specifically someone can mentor me to push stuff if needed ?
Re: Questions
Thx Yes it is (helpfull). I already know some stuff i just need to make stuff i need works. :) I first come here for some data approch too. Do you think about more data like ebooks that can be great to have ? where each application basically just has its own sandboxed home folder => most stupid thing in the world We need an appropriate data security policies tool with an real identity manager. And i currently try to working on a such tool. If people here have ideas feel free to share. J. On 20/11/2021 20:15, Elsie Hupp wrote: Hi Jérôme, The Arch Wiki has a pretty good guide to the `xdg-user-dirs` package installed on most Linux distributions: https://wiki.archlinux.org/title/XDG_user_directories I’ve dug around in the boilerplate code for *looking up* `xdg-user-dirs`, and it basically queries `XDG_FOOBAR_DIR` for `FOOBAR`, so you *should* basically be able to define any custom folder you want. You can check out my pending pull request on `pyxdg` for a version of the code that’s somewhat easier to read than the original C: https://gitlab.freedesktop.org/xdg/pyxdg/-/merge_requests/13 The actual Python file: https://gitlab.freedesktop.org/xdg/pyxdg/-/blob/8fa45fbbe4cd6676b388ca0549f875739301ed21/xdg/UserDirectory.py Note that this is a simplified line-by-line translation of `xdg-user-dir-lookup`: https://gitlab.freedesktop.org/xdg/xdg-user-dirs/-/blob/master/xdg-user-dir-lookup.c However, a big part of the functionality behind `xdg-user-dirs` is (a) the basic list is standardized across most Linux distros, and (b) the actual name of the directory is localized into a large number of natural languages. The main reason actually that I joined this mailing list was to ask about directories for difficult-to-categorize use cases, like ebooks or podcasts (or code repositories or, yes, games). So, hypothetically, yes, you could define your own `xdg-user-dirs`. However, `xdg-user-dirs` is a tool rather than standard, and even if you got a pull request approved for some additional directory, it would probably take years to percolate out through the install base and never actually reach 100% of users. Oh, and you’d also need to get it adopted by both GLib and Qt. (Qt would probably be easier, considering Windows does IIRC have a `My Games` directory, so there’s already a cross-platform precedent.) This is to say that if you define your own custom directories in `xdg-user-dirs` in application code, you should always define a fallback. And in some respects `xdg-user-dirs` is kind of falling out of fashion with the rise in Flatpak and Snap for end-user applications, where each application basically just has its own sandboxed home folder, rather than using a shared per-content-type directory, even though Flatpak portals do increasingly support arbitrary locations in userspace. Anyway, I hope this is helpful! Best, Elsie Hupp On Nov 19, 2021, at 3:51 PM, Jérôme Bardot wrote: Hello, There is a way to to add this own stuff in XDG_CONFIG_HOME/user-dirs.dirs ? I want a XDG_GAMES_DIR= Also can i access to XDG var from a shell ? thx More specifically someone can mentor me to push stuff if needed ?
Re: Cleaning of $XDG_CACHE_HOME and $XDG_CACHE_HOME/thumbnails
On 26/02/2020 14:30, Benjamin Berg wrote: > On Wed, 2020-02-26 at 14:22 +0100, Bastien Nocera wrote: >> On Wed, 2020-02-26 at 13:45 +0100, Benjamin Berg wrote: >>> Now, systemd-tempfiles can already clean up everything except for the >>> trash. And considering that $XDG_CACHE_HOME is non-essential by >>> definition, I think it might be sane to use systemd-tempfiles not only >>> to clean the thumbnails but the entirety of $XDG_CACHE_HOME in the >>> future. >> >> It's not "non-essential", it's a cache, which can be regenerated, but >> it might be utterly costly to do so. Eg. there are 10 gigs of "cached" >> evolution mails in my ~/.cache, 5 gigs of jhbuild builddirs. >> >> Nuking it is a last ditch scenario. You'd avoid backing it up on space >> constrained storage, but you'd want to avoid having to regenerate that >> cache in most cases. > > I am *not* proposing to nuke these directories. I am proposing to nuke > them by default, and ask applications like evolution, jhbuild and > others to ship their own configuration. > I’m not sure a destructive by default behavior is a good thing even on a cache directories. I’m pretty sure this will lead to a lost of data. > This matches the behaviour of /tmp and /var/tmp on systemd managed > systems. In the simplest case, all evolution needs to do is ship a one > line file with: > > x %C/evolution > > This file can even be installed to the users $XDG_CONFIG_DIR for > applications that might not be able to do it globally. > Not all GNU/linux comes with systemd. Protocol and specification over tools/implementation specific. If it come restrictive it’s not good. Exept for security stuff and even in this case it’s not always a good choice. (for ie : 2fa when only choice is a phone) >> >>> Is it reasonable to standardise on the systemd tmpfiles.d format? >>> Is it OK to clean $XDG_CACHE_HOME after a fixed time period by >>> default? >> >> I'm guessing that's a no. >> >> As for thumbnails, you'd probably get away with checking whether atime >> is actually set on that mount and cleaning up the ones that haven't >> been used. > > Benjamin > > > ___ > xdg mailing list > xdg@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/xdg > 0x053A41EF03878A98.asc Description: application/pgp-keys ___ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg
Re: xdg-basedir for secrets
Le 06/06/2019 à 23:15, Jonas DOREL a écrit : > Hi, > hi > Currently, most secrets (SSH Keys, GPG Keys, OAuth token) seems to be > located in XDG_CONFIG_HOME. And they should not, secrets are data not config. (for me) > > However I think one of the interests of the XDG basedir specification is > to facilitate the management of those different files (backup, > publication, mount, ...) because of the different policies applying to > those files. For me as far as possible all /home data should have an as strict as possible policy. > > But it don't think secrets should be handled the same way as > configuration. What do you think about adding XDG_KEYS_HOME (maybe > .secrets or .local/secrets) and XDG_KEYS_DIR ? If we start to manage things by there purpose (and we should (my point of view)) some others concern will be. if i do it for my emails, or my calendars, or my bookmark we need a strict policy behaviours. Which program can access at what. And what about the storage (xml/txt/maildir/vbox etc). For me storage should be program agnostic. (the same data should be use by the user prefered software) but my last email about that not look really welcome. I m not part of anything so it’s maybe for that but i’m glad to see I m not alone with this kind of ideas. > > Jonas DOREL > jerome sry for my bad english > ___ > xdg mailing list > xdg@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/xdg 0x053A41EF03878A98.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg
