GNOME Bugzilla – Bug 647873
Sources should be created in GConf
Last modified: 2011-04-19 06:12:24 UTC
This was originally filed here: https://bugs.meego.com/show_bug.cgi?id=12752 as "Tasks don't get saved across reboots". The root of the problem is that the e_cal_new_system_* methods are not creating the corresponding sources in GConf. So even though (i.e.) tasks would be saved to ~/.local/share/evolution/tasks, e-d-s would fail to "see" them because the corresponding source weren't saved in GConf. Bug #546825 might be fixed by addressing this issue. dwmw2's branch: http://git.infradead.org/evolution-data-server-2.32.git/shortlog/refs/heads/gnome-2-32 fixes the issue.
In EDS master: commit 3bb75464a6774b25cacb070959f4eb0465fd665c Author: David Woodhouse <David.Woodhouse@intel.com> Date: Fri Apr 15 12:19:00 2011 +0100 Bug 647873 [2/2] - e_cal_new_system_foo() should create source in GConf commit 05c0b7b4bd06c9df459626e09713746d5efa2169 Author: David Woodhouse <David.Woodhouse@intel.com> Date: Fri Apr 15 12:20:04 2011 +0100 Bug 647873 [1/2] - Fix comparison of URI in e_cal_new_from_uri(). If the URI only had a relative_uri property, we should build the full URI for comparison rather than just skipping it. Otherwise we get false mismatches. We should backport these to 3.0 (and 2.32) too, but the commit 2/2 has added translatable strings "On This Computer" and "Personal", so need to seek approval for that. In fact, "Personal" was already translated. I think that "On This Computer" once was in e-d-s too, but isn't now. It *is* translated in evo itself though, so I can easily copy the translations across all at once rather than leaving it to the translators to do it one language at a time.
Pushed translations too (lifted from the Evolution repository), and also pushed to 3.0 and 2.32.
*** Bug 546825 has been marked as a duplicate of this bug. ***
*** Bug 546589 has been marked as a duplicate of this bug. ***
The e_source_get_uri() has a side-effect, it stores the absolute uri to settings, thus the next start this is there. I've a feeling it makes trouble with some sources, maybe with local sources, but I cannot recall precisely. Having more time I would comment before you committed this on your own...
So that would potentially change the behaviour of any code which looks only at the absolute URI and *not* at the relative URI. And in particular it would be code which is currently seeing *no* absolute URI, and would suddenly see a URI where previously there was none. Such code is surely buggy, and its behaviour could be changed by *anyone* calling e_source_get_uri() on an ESource from an ESourceList which is later going to be changed? The buggy code that we fixed here is an example of precisely that, and perhaps your feeling is from a vague memory of this bug itself? Or perhaps you're thinking of the issue I described in http://mail.gnome.org/archives/evolution-hackers/2011-April/msg00059.html which is the *opposite* problem; it looks only at the *relative* URI and not the absolute URI. We *could* perhaps change this fix so that it reimplements e_source_get_uri() for itself without the side-effect. But I'm not sure we should. In fact, looking at the code I'm not even 100% sure you're right; I don't see where ->absolute_uri gets *set* in e_source_build_absolute_uri() ...?
We had a chat on this on IRC and the result was that this is just my feeling, I've no exact clues and I'm basically fine with the change. > We *could* perhaps change this fix so that it reimplements e_source_get_uri() > for itself without the side-effect. But I'm not sure we should. > > In fact, looking at the code I'm not even 100% sure you're right; I don't see > where ->absolute_uri gets *set* in e_source_build_absolute_uri() ...? Of course, e_source_build_absolute_uri() is used to create the uri, and its result can be used either on its own, or to set the internal absolute_uri. Thus it does what you want for both above things. But really, keep it as it is for now, and we'll see in a time whether anything arises or not. My feelings are only feelings.