Laurent MONIN wrote: ::snip? SNIP!:: > geeqierc and other conf files are going to: > $XDG_CONFIG_HOME/geeqie/ (default to $HOME/.config/geeqie/). > > metadata and thumbnails cache (if std is not used) are going to: > $XDG_CACHE_HOME/geeqie/metadata/ (default to $HOME/.cache/geeqie/metadata/) Shouldn't metadata go to $XDG_DATA_HOME? Keywords and comments, among other things, are irreplaceable and cannot be auto-generated, so I don't think they'd be appropriate for the cache directory.
> and $XDG_CACHE_HOME/geeqie/thumbnails/ (default to > $HOME/.cache/geeqie/thumbnails/) What about ~/.thumbnails? This definitely seems like a step in the wrong direction, since photo apps would no longer be able to easily share thumbnails. > collections are going to: > $XDG_DATA_HOME/geeqie/collections/ (default to > $HOME/.local/share/geeqie/collections/) (general response) Admittedly, I'm loath to think that splitting things up by default is a good idea — the Windows Registry already went down this path, and it's an absolute nightmare to remove apps manually. Of course, this XDG stuff does have a reasonable use-case in allowing apps to work in all sorts of "distributed" environments (with shared, read-only config partitions, or shared caches, or other stuff like that). So, basically, it seems like this won't really benefit most users, but for the few who need it, it'll be tremendously useful. As far as the trash spec, I think it's a good idea to implement it, and possibly to turn it on by default. (Note: I haven't actually read it yet) However, there should still be the ability to send deleted bits straight to the bitbucket. This switch is especially useful if you looking through a lot of large photos, and a two-stage "delete" would cause geeqie to do a cross-partition copy to the partition with the Trash folder on it. It would also be useful if you don't use Trash in the first place, and don't want that folder to become chock full of things you thought were already gone. > Should we move to XDG now ? Not, right now, no. As I said above, it doesn't actually help most of our userbase. And the whole "something's not working? try moving your .geeqie out of the way to see if that helps" becomes a _lot_ harder and more involved. I think it'll be telling to see (1) what sorts of interesting use cases people come up with over the coming months, and (2) how many other apps adopt the standard. > Should we offer optionnal support for it (how) ? It should definitely be an option. If the extra stat()s wouldn't hurt too much (I dunno), it'd probably be pretty easy to look for stuff under .geeqie, then in the XDG places as well. (This could be implemented by just prepending the .geeqie/something file/path to the search path for whatever, which could also help keep the number of code paths down) As far as writing a config file, it seems less easy to automatically decide between .geeqie/... or $XDG_CONFIG_HOME/... > How to handle the move between older versions and new ones ? If geeqie supports both .geeqie and $XDG_CONFIG_HOME, this could just be a no-op. We could probably also include a shell script or something to migrate files from .geeqie to the appropriate places, and if we find that the standard becomes well-adopted and is useful, could run this script on startup (likely with an opt-out UI of some sort) for new versions that detect the existence of .geeqie/ > Should we implement the trash spec as proposed in feature request #1950978 ? Yes, but with the ability to skip the trash and kill the bits directly, as noted above. --xsdg ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
