The GEGL cache is another very good example of why hijacking XDG variable is wrong. Well they are not actually lost, but from the user's point of view, that's searching on the web, asking on forums until finally discovering one has to manually move files from a hidden directory to another => bad experience). they would all be lost if one used a distribution package, then later a flatpak. This one, I am very annoyed because I completely disagree with "hijacking" the XDG variables and bypassing the user data (if one had brushes, plugins, etc. I could actually sum it up in 2 issues:ġ/ Access to desktop data, for instance user bookmarks, thumbnails… I guess this should likely be solved by portals as was noting.Ģ/ Access to its own data as specified in the Freedesktop specs (and in particular the XDG directories). But this issue is really blocking me because that's not good user experience. So I have been playing with flatpak a few days ago, making a flatpak for GIMP since I would like us to have an official flatpak for our releases. the old value of $XDG_CONFIG_HOME) should be mounted as ~/.var/app/$app/config/gtk-3.0/. So in your previous example $XDG_CONFIG_HOME/gtk-3.0/ (i.e.
#Gimp stuck on looking for data files fonts software
This way, we have no compatibility problem forward nor backward.įor instance, we could have the app specify that ~/.config/gtk-3.0 should be mounted as ~/.var/app/$app/config/gtk-3.0.Ĭan this be done also for the software config dir? Also since you redefine $XDG_CONFIG_HOME, it would be good if the old value is kept around. That's what we do with GIMP (you'll notice that our config dir is $XDG_CONFIG_HOME/GIMP/). Well IMO, that's up to these libraries to deal with this, for instance by using versionned directory names. its often compatible going forward, but not backwards). Such configuration can easily break as you change library versions (i.e. Some libraries also store config in ~/.config. Applications are not supposed to redefine these variables (if set, they are user-defined). It took years to finally have most applications follow this specification and getting away from the every-app-with-custom-config-dir pain, and now breaking this is like a step back.
I understand wanting to isolate per-app data, but I really can't say I like the hijacking of the XDG directories to create another directory with the same purpose. For instance, what if the settings.ini file in that directory refers to an icon theme in /usr that the app can't see. And also that they are self-contained and don't rely on other things from the host. Of course, that would mean guaranteeing that these config files are both forward and backwards compat for all gtk3 versions forever. For instance, we could have the app specify that ~/.config/gtk-3.0 should be mounted as ~/.var/app/$app/config/gtk-3.0. We could add library specific workarounds though, so that you can use the shared config for something you have verified is safe to share. So, I think the current way flatpak works is the least problematic as a general solution. This also breaks with flatpak, which would run multiple library versions, maybe even in parallel, against a shared config dir. Also, anything that stores binaries or plugins there will not work because the dependencies in that may be incompatible with the one in the runtime.
For instance, the desktop files and mime files are inherently tied to the host /usr, and for things like recent files sharing gets complicated because apps may see different subsets of the filesystem. I think its a somewhat of a problem that $XDG_DATA_HOME contains both shared (desktop files, mimetypes, thumbnails, bookmarks, recent files) and per-app configuration, because is a more separated "app" world we really do want the per-app data to be isolated, but on the way there apps are still going to be given homedir access, which means they could use at some of the shared configuration.
0 kommentar(er)
