Show only Evolution calendar events if the calendar is active

Bug #729033 reported by David Planella on 2011-03-04
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Indicator Date and Time
Fix Released
Karl Lattimer
indicator-datetime (Ubuntu)

Bug Description

I've got several calendars in Evolution, some of which are not active (i.e. the checkbox is not ticked in Evolution).

The Date and Time indicator still shows me the events for those, where I would expect that unmarking them is a signal that while I want to keep them, I'm not interested in seeing their events.

Related branches

Changed in indicator-datetime:
assignee: nobody → Karl Lattimer (karl-qdh)
Karl Lattimer (karl-qdh) wrote :

This is currently difficult - I'm trying to find the configuration variables used by evolution but I'm not having a lot of luck. Thanks for filing this bug it'll help me keep track of it.

Changed in indicator-datetime:
importance: Undecided → High
status: New → In Progress
Changed in indicator-datetime (Ubuntu):
importance: Undecided → Low
importance: Low → High
importance: High → Low
Karl Lattimer (karl-qdh) on 2011-03-23
Changed in indicator-datetime (Ubuntu):
status: New → Confirmed
Karl Lattimer (karl-qdh) wrote :

I've looked through the gconf keys which stores an XML string which doesn't appear to have any obvious identifying feature, I've looked through various xml files in the .evolution folder and nothing seems to have anything which pertains purely to whether or not the calendar is activated in the UI or not.

The evolution mailing list points to a decision to use a GKeyFile instead of gconf or dconf for future releases but I'm not sure whether or not that's actually been implemented in our current release.

Changed in indicator-datetime:
status: In Progress → Incomplete
Changed in indicator-datetime (Ubuntu):
status: Confirmed → Incomplete
Karl Lattimer (karl-qdh) on 2011-04-04
Changed in indicator-datetime:
status: Incomplete → In Progress
Karl Lattimer (karl-qdh) wrote :

It appears the chunk of XML that was in GConf is no longer there. Instead there now appears to be a /apps/evolution/calendar/selected_calendars key in GConf.

I've checked and this is usable so I'll start writing a fix now :)

Karl Lattimer (karl-qdh) wrote :

it appears the URI's in the selected_calendars key does not match the value of e_cal_get_uri always.

Minimum difference is a pre-pended "local:" which isn't a major issue at worst the URIs are abbreviated to contacts:/// and local:system

Trying to find a resolution to that with mbarnes

Karl Lattimer (karl-qdh) wrote :

Conversation log with mbarnes

(12:57:41) klattimer: mbarnes: is there any way to turn local:system into local:stringofnumbersanddots@machine?
(12:58:21) klattimer: or even looking up the system calendars URI in any way so I could compare like for like
(13:00:49) mbarnes: well, "system" is a special UID corresponding to your "Personal" calendar. it's always there.
(13:01:03) klattimer: mbarnes: but it is NOT saved in the preferences as "system"
(13:01:14) klattimer: it is saved in preferences as a string of numbers, dots and the machine name
(13:01:17) klattimer: as are the others
(13:01:57) klattimer: GConf -> /apps/evolution/calendar/display/selected_calendars
(13:02:02) klattimer: shows only normal URI's
(13:02:07) klattimer: not system
(13:02:11) klattimer: or calendar:///
(13:02:14) rodrigo_ [] entered the room.
(13:02:18) mbarnes: ah, you're right. crap.
(13:02:28) mbarnes: this URI stuff is so broken
(13:02:32) klattimer: yeah, this kind of thing can make writing client applications impossible4
(13:03:01) klattimer: so, is there any way of getting the URI for system
(13:03:02) mbarnes: fwiw, I'm doing away with URIs entirely when we move to key files. we'll just use the UIDs everywhere.
(13:03:07) klattimer: or finding out the real URI of system
(13:03:34) klattimer: mbarnes: that doesn't help the current situation, but it's good to know it will change

Karl Lattimer (karl-qdh) wrote :

Attached a branch which would work if it weren't for broken eds URI handling

Karl Lattimer (karl-qdh) wrote :

Will try this suggestion next;

(13:07:58) mbarnes: if using the APIs do the following: obtain the ESourceList for calendars, call e_source_list_peek_group_by_base_uri(list, "local:"), then iterate over the sources in that group looking for one with relative_uri="system", then call e_source_peek_uid() on it

Karl Lattimer (karl-qdh) wrote :

Updated the branch now includes a working patch!

Ted Gould (ted) on 2011-04-04
Changed in indicator-datetime:
status: In Progress → Fix Committed
milestone: none → 0.2.2
Ted Gould (ted) on 2011-04-07
Changed in indicator-datetime:
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package indicator-datetime - 0.2.2-0ubuntu1

indicator-datetime (0.2.2-0ubuntu1) natty; urgency=low

  [ Ted Gould ]
  * New upstream release.
    ∘ Add language and proper distro version to geonames URL to allow
      for proper server side fixes
    ∘ Give full day events the day name instead of a time
    ∘ Make sure the calendar follows the user setting (LP: #748772)
    ∘ Ensure that events handle month boundaries correctly (LP: #746713)
    ∘ Only show calendars the user has configured (LP: #729033)
    ∘ Reenable clicking on the timezone in the menu to set it.

  [ Ken VanDine ]
  * debian/control
    - Added build depends for libgconf2-dev
 -- Ken VanDine <email address hidden> Thu, 07 Apr 2011 14:53:52 -0400

Changed in indicator-datetime (Ubuntu):
status: Incomplete → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers