Omari Stephens a écrit :
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.
Yes, i agree. I will fix it.
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.
Note that ~/.thumbnails is used for the shared cache (standard
conforming thumbnails),
this is not affected by this change which only concerns unshared
thumbnails (path is .geeqie/thumbnails by default).
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.
I agree with this point. I'm not fond off XDG spec.
I prefer the $HOME/.appname convention.
But this feature is requested by some users.
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.
Implementing trash spec isn't trivial imho.
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.
I agree.
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)
Yes.
As far as writing a config file, it seems less easy to automatically decide
between .geeqie/... or $XDG_CONFIG_HOME/...
We'll have to ask the user on first start or it should be defined
system-wide (or by distribution packagers) ...
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/
Geeqie have to support both imho.
A migration script should be fairly easy to code.
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.
This ability already exists (called Safe Delete).
--xsdg
--
Laurent Monin aka Zas
-------------------------------------------------------------------------
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
