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 546589 - ecal.list_task_sources() returns an empty list
ecal.list_task_sources() returns an empty list
Status: RESOLVED DUPLICATE of bug 647873
Product: gnome-python-desktop
Classification: Deprecated
Component: evolution
2.23.x
Other Linux
: Normal normal
: ---
Assigned To: John Stowers
Python bindings maintainers
Depends on:
Blocks:
 
 
Reported: 2008-08-06 13:33 UTC by Patryk Zawadzki
Modified: 2011-04-15 21:01 UTC
See Also:
GNOME target: ---
GNOME version: 2.23/2.24



Description Patryk Zawadzki 2008-08-06 13:33:57 UTC
Currently:

In [1]: import evolution
In [2]: evolution.ecal.list_task_sources()
Out[2]: []

It used to return a working cal and I do have tasks defined in e-d-s. Right now hamster-applet and conduit are unable to read TODO items stored in e-d-s.
Comment 1 Gian Mario Tagliaretti 2008-08-06 14:02:00 UTC
Patryk this is weird, the code in g-p-d has not changed in months and the method doesn't do anything special:

override evo_environment_list_task_sources noargs 
static PyObject*
_wrap_evo_environment_list_task_sources(PyGObject *self) 
{
    GList *list = NULL;
    list = evo_environment_list_cal_sources(E_CAL_SOURCE_TYPE_TODO);
    return _helper_wrap_glist_of_evo_locations(list);
}

Maybe a change in evo_environment_list_cal_sources itself?
Comment 2 Patryk Zawadzki 2008-08-06 14:14:57 UTC
I'm puzzled.

Upon further digging it seems the problem is there is no /apps/evolution/tasks/sources in gconf (that's what e_cal_get_sources returns) on my system.

Yet Tasks works fine. I don't have Evolution installed at all.

There seems to be a e_cal_new_system_tasks API call exposed by e-d-s but not in Python bindings.
Comment 3 Patryk Zawadzki 2008-08-06 14:19:42 UTC
Checked Tasks sources - it seems to always call e_cal_new_system_tasks and never even tries to look for TODO source types. Makes sense as IIRC Evolution won't allow you to create more or less than one such source.
Comment 4 Patryk Zawadzki 2008-08-07 15:59:17 UTC
See also bug #546825.

As a workaround if ecal.list_task_sources yields an empty list I use:

evolution.ecal.open_calendar_source('default', ecal.CAL_SOURCE_TYPE_TODO)

as a fallback.

Adding Conduit maintainers to CC as they are likely affected.
Comment 5 Patryk Zawadzki 2008-08-07 16:00:31 UTC
Haha, sorry about the CC part, only realized you are the maintainer of both after pressing submit, not enough coffee ;)
Comment 6 Gustavo Carneiro 2009-02-24 11:11:18 UTC
Works for me:

>>> import evolution
[55805 refs]
>>> evolution.ecal.list_task_sources()
[('Pessoal', 'file:///home/gjc/.evolution/tasks/local/system')]
Comment 7 John Stowers 2009-02-24 12:08:19 UTC
(In reply to comment #6)
> Works for me:
> 
> >>> import evolution
> [55805 refs]
> >>> evolution.ecal.list_task_sources()
> [('Pessoal', 'file:///home/gjc/.evolution/tasks/local/system')]
> 

Works for me to. 

I actually asked on IRC about this. There was a transient bug in e-d-s about how it treated default sources, but I think the behaviour was subsequently fixed and I forgot to close the bug.

I would also be interested to see if anyone else still sees this. I dont.
Comment 8 Patryk Zawadzki 2009-02-24 12:35:47 UTC
In [2]: evolution.ecal.list_task_sources()
Out[2]: []

I am still affected by this. It seems the bug in e-d-s is no longer there but it did not actually fix the configuration so the default is still not listed there.

In [4]: evolution.ecal.open_calendar_source('default', evolution.ecal.CAL_SOURCE_TYPE_TODO)
** (process:28779): DEBUG: Opening calendar source uri: default

Out[4]: <ecal.ECal object at 0x83ce52c (ECal at 0x8448ea0)>
Comment 9 David Woodhouse 2011-04-15 21:01:36 UTC
I think the remaining issue was fixed, as bug #647873

Please reopen, or perhaps file a new bug, if there is still a problem.

*** This bug has been marked as a duplicate of bug 647873 ***