timetrap
timetrap copied to clipboard
samg
Support for XDG specification
Allowing for the XDG Base Directory Specification would be fantastic, and it's extremely easy to implement. For instance, first check for files that would be expected via $XDG_CONFIG_HOME (~/.config/timetrap/ for config.y[a]ml, etc), and if nothing is found, proceed to load in the current fashion (~/.timetrap, etc).
More on the specs here: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
I would be willing to work on this, but if I do, I would like to not only change the path for the configfile (currently defaulting to $HOME/.timetrap.yml), but also change the default paths for formatters and auto-sheets. I would suggest to implement like this:
| Usage | Path |
|---|---|
| Config File | $XDG_CONFIG_HOME/timetrap/config.y[a]ml |
| Formatters | $XDG_CONFIG_HOME/timetrap/formatters/ |
| Auto Sheets | $XDG_CONFIG_HOME/timetrap/auto_sheets/ |
| Database File | $XDG_DATA_HOME/timetrap/timetrap.db |
Please note the different path for the database file, since the databse clearly is "data", $XDG_DATA_HOME would fit the specs best IMHO.
One thing I am unsure about is, how we should handle "old default paths", personally I would prefer to move existing data/files from old paths to new paths (so NOT falling back to old paths and instead "cleanup" by moving files to XDG base directories)... But I'd like to get some feedback/opinions here.
Another question/discussion would be, how to proceed if $XDG_CONFIG_HOME and/or $XDG_DATA_HOME is simply not set on the system? pam_systemd for example is by default only setting $XDG_RUNTIME_DIR. Personally I would prefer (and in fact this is also what the XDG Base Directory specs suggest) to use the XDG-Defaults, which are $HOME/.config and $HOME/.local/share.
What do you guys think about it? :)
:100: agree with your decision, both to convert everything to the spec as well as your question on sane defaults.
@akiva I'd assume that you closed this Issue by mistake, right? 😅
My suggestion would be to support the old location (say, read it if it exists) but notify the user with a warning that a new default is in place and probably add an option to migrate.
My suggestion would be to support the old location (say, read it if it exists) but notify the user with a warning that a new default is in place and probably add an option to migrate.
yeah sounds good to me @categulario, will take this into account. guess with a simple (Y/n) input, and storing this decision anywhere, to make sure the user is not forced to answer this question all over again, we should be good to go :)