On Wed, 2011-03-23 at 17:41 +0100, Hans de Jonge wrote:
> Op dinsdag 22 maart 2011 15:08:57 schreef Patrick Ohly:
> > I suppose I must reread our older mail thread about config changes
> > coming in 3.0, but let shoot of a quick question anyway: further config
> > changes are coming in 3.0 that will replace this XML blob, right?
I think I missed Patrick's reply, but as I clarified for him on a
different mailing list thread, the config changes missed 3.0 and are
targeted now for 3.2. But yes, the primary goal is to replace the XML
blobs in GConf with easy-to-read/easy-to-edit key files that live within
your evolution data directory.
I'm also doing away entirely with using URIs to reference configured
calendars, address books, etc. It finally dawned on me that the way
we've been using these URIs since about forever is actually broken and,
in my view, is just making things needlessly complex. This issue with
the file backend is a perfect example.
Instead, these "ESources" as we call them, which describe and hold
settings for a calendar or address book (and soon, mail accounts), will
be identified exclusively by the unique identifier string (UID) they
already have.
I'll be introducing a global singleton registry object to hold all these
ESources, which can be queried in a number of ways including by UID.
End result will hopefully be a much simpler and more robust account
management design for E-D-S than what we've been living with.
> > So would the following work for Hans?
> >
> > - move /home/hansdej/.SyncEvolution/Calendar/calendar.ics
> > to /home/hansdej/.local/share/evolution/calendar/syncevolution.ics
> > - change evolutionsource to "local:syncevolution.ics"; this will be
> > used as URI
Not quite. You'll need to make up a UID string for the calendar, let's
say "syncevolution", and then insert an XML <source> element in the
appropriate blob in the /apps/evolution/calendar/sources GConf key.
Then within that <source> element, add a child element like so:
<source uid="syncevolution" ...>
<property name="custom-file" value="/path/to/syncevolution.ics"/>
</source>
Then the URI for the calendar would be "local:syncevolution".
Yes it's a PITA right now, and for this particular use case could be
viewed by some as a regression from the earlier file:// URIs. It's best
to configure this through Evolution, or at least programmatically using
the ESource/ESourceGroup APIs that can spit out the XML for you.
FWIW, after the planned changes have landed for 3.2, configuration for
this same calendar will be as follows:
You'll have a file ~/.local/share/evolution/sources/syncevolution with
contents that look something like:
[Data Source]
DisplayName=My SyncEvolution Calendar
Parent=local
[Calendar]
Color=#rrggbb
Enabled=true
WritableHint=true
[Local Backend]
CustomFile=/path/to/syncevolution.ics
The key file's basename becomes the ESource's unique ID; "syncevolution"
in this case.
Hope all this rambling helps...
Matthew Barnes
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
