After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 647873 - Sources should be created in GConf
Sources should be created in GConf
Status: RESOLVED FIXED
Product: evolution-data-server
Classification: Platform
Component: Calendar
unspecified
Other Linux
: Normal normal
: ---
Assigned To: evolution-calendar-maintainers
Evolution QA team
: 546589 546825 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-04-15 15:07 UTC by Raul Gutierrez Segales
Modified: 2011-04-19 06:12 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Raul Gutierrez Segales 2011-04-15 15:07:14 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.
Comment 1 David Woodhouse 2011-04-15 15:16:35 UTC
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.
Comment 2 David Woodhouse 2011-04-15 20:58:52 UTC
Pushed translations too (lifted from the Evolution repository), and also pushed to 3.0 and 2.32.
Comment 3 David Woodhouse 2011-04-15 20:59:43 UTC
*** Bug 546825 has been marked as a duplicate of this bug. ***
Comment 4 David Woodhouse 2011-04-15 21:01:36 UTC
*** Bug 546589 has been marked as a duplicate of this bug. ***
Comment 5 Milan Crha 2011-04-18 13:26:57 UTC
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...
Comment 6 David Woodhouse 2011-04-18 14:49:17 UTC
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() ...?
Comment 7 Milan Crha 2011-04-19 06:12:24 UTC
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.