Remove dependency on gconf

[GeraldJansen]

• completely remove gconf dependency (also in waf scripts)
• save/load configuration in xdg_config_home, normally ~/.config/hamster-time-tracker/hamster.json
• for now the file is accessed on every conf.set() and conf.get() call (meaning that external modifications will be picked up immediately)

Related to #64. Perhaps a complex migration is not necessary.

[ederag]

Sorry, as i said, this will have to wait after v3.0.

[GeraldJansen]

Okay, I guess it's ready when you are.

[ederag]

OK, it was not clear that it was work in progress,
and I do not want to give the impression that PR are ignored, especially PR from you 😄.
I understand the value of this work, both as a proof of concept,
and as a solution for distributions that are going to drop gconf.

But really I feel that handling configuration (with eg. file monitoring), is no small feat.
Gsettings migration is probably not that difficult, since its documentation about migration is a bit scarce,
and that would be a standard, well debugged solution.

What I would recommend is not implementing fancy file monitoring,
keep this proposition as simple as possible, to have a branch working around gconf disappearance,
requiring to restart hamster for any external change.
But maybe that was your intention all along ?
If you go too far, I will feel compelled to use so much work done
(that's already the case, even with the warning given).

[GeraldJansen]

My proposition is to move to very simple config file to handle our handful of configuration values. The file is re-read or re-written for every single access to any setting (i.e. conf.get('setting_name') or conf.set('setting_name, value), so no other file monitoring is needed. Not pretty or efficient or robust, but this little application doesn't need anything more complicated or robust, just like it doesn't need a more robust DB than sqlite3 for the real data storage. I have tested this, including external editing of settings, which are picked up immediately (well, the next time hamster needs to use the modified parameter).

[ederag]

Even more interesting, but still need to think, later.

[bgamari]

I'll admit, I'm not sure I see the rationale for this direction. It seems like the course of least resistance here would be to simply move to GSettings. Adapting the schema should be trivial and the GSettings interface is reasonably similar to GConf.

As has been pointed out, configuration management is not trivial and the ad hoc solution proposed here almost certainly won't be as robust as using a library. Let's avoid reinventing the wheel if possible.

[GeraldJansen]

Okay, forget it. Release a new version of a Gnome software in 2019 still depending on gconf when Gnome itself abandoned gconf in 2011. Looking forward to someone else's better solution.

[ederag]

Dear @GeraldJansen

Release a new version of a Gnome software in 2019 still depending on gconf when Gnome itself abandoned gconf in 2011

Looks like a direct criticism to me.
This is unfortunate, true.
But please understand that all distributions were shipping it until recently.

Maybe it should be added that I did look into this configuration stuff maybe a year ago,
and again before the waf update.
GSettings migration was not obvious,
but others managed to do it, and it is standard (this is my point of agreement with @bgamari).
and while reading about that (in particular why they abandoned gconf),
I learned enough to be a bit scared of rolling our own one.

Your proposition is interesting too,
it has some elegance (apart from the frequent disk accesses).
Please do not delete it.

On the contrary, I would really encourage you to merge master into this PR often,
so that others can have a working solution until the decision is taken.

There might be a source of misunderstanding:
all the work you see emerging now does not mean I have a lot of time,
nor that it has higher priority,
but it was started long ago, it makes a whole
(for instance #461 (comment))
and I need to see it finished.

Hoping you understand and we can continue united;
as I'm really drained and in no state to take any decision about this.

[GeraldJansen]

@ederag Sorry for the sharp response in a moment of frustration. Looking forward to #470. Great to see a new contributor, really!

[bgamari]

Thanks @GeraldJansen! Quite alright, I think we've all been there :)

[ederag]

@GeraldJansen It's OK, because your impetus usually helps this project,
although this time it was on the "uncomfortable" side.

Now I would not like this project to lose two motivated contributors,
so we'll see if it can both make it into v3.0 and be released before the ubuntu feature freeze.
No promises at all, warning has been given earlier, and the following months will be very busy.