On Tue, 2010-07-20 at 11:21 +0530, chen wrote:
Is it required ? Having it in ECalBackendStore simplifies the backend
code to form the path based on the type (calendar,tasks,memos) at a
single place rather than every backend doing it..
Forming the path at a single place instead of all the
On Tue, 2010-07-20 at 06:34 -0400, Matthew Barnes wrote:
On Tue, 2010-07-20 at 11:21 +0530, chen wrote:
Is it required ? Having it in ECalBackendStore simplifies the backend
code to form the path based on the type (calendar,tasks,memos) at a
single place rather than every backend doing it..
On Tue, 2010-07-20 at 11:21 +0530, chen wrote:
On Mon, 2010-07-19 at 17:27 -0400, Matthew Barnes wrote:
Backends using these classes can easily construct a suitable cache file
or directory name from e_cal_backend_get_cache_dir().
get_cache_dir can simply return e_cal_backend_store_get_path.
On Sun, 2010-07-18 at 20:34 -0400, Matthew Barnes wrote:
Only reason I wrote them for the client-side libraries is
because e_cal_get_user_cache_dir() is used to figure out where to
cache ECal attachments in set_local_attachment_store().
Hi,
that's a part which should be changed. The
On Mon, 2010-07-19 at 17:27 -0400, Matthew Barnes wrote:
On Mon, 2010-07-19 at 09:10 +0200, Milan Crha wrote:
that's a part which should be changed. The ideal way, as I understand
it, is to have an ECalBackend function to retrieve a path for
attachments, and ECal should ask backend for it,
As part of the XDG base directory effort, I've written a couple simple
functions for libebook and libecal:
gchar *
e_book_get_user_cache_dir (const gchar *source_uri);
gchar *
e_cal_get_user_cache_dir (const gchar *source_uri,
