Re: supporting unlisted calendar source uris


On 6/30/07, Thomas Viehmann <tv+conduit-list beamnet de> wrote:

would it be worthwile to support opening calendar uris that are not
listed in the source list?

Im not sure of the use case for this at the moment. Under what situation is a source not listed in the source list?

Doing so would (according to my very limited testing) basically
amount to resorting to call e_source_new_with_absolute_uri when
e_cal_get_sources fails in evo_cal_source_open_source (in

The question likely is whether to do this via an optional parameter
in (the python function) evolution.open_calendar_source or put it in
a new function. Also, it would likely be desirable to be able add the
source to evolution's list of sources, even though that isn't
necessary (or desirable) in the application I presently have in mind.
I'm not quite sure what other bookkeeping would need to be done.

The current approach is not the best (the code is quite convoluted to work around bug and I wanted to keep the code similar in structure to the evo_open_ addressbook code.

I can understand that one might want to create a calendar with a source at a specific filesystem location but I thought that this calendar source would then appear in the list of sources the next time evo_environment_list_cal_sources is called?

If you are not opposed to introducing calendar creation in general
and could give me a hint on the above, I'd try to come up with a

I would like to keep the python api similar in appearance to the C api so I am not opposed to wrapping e_source_new_with_absolute_uri as a seperate function as opposed to kwargs to the current open function.

I hope evo-python can be useful in your application


Kind regards


P.S.: Sorry for introducing myself with a feature request.
Thomas Viehmann,
Conduit-list mailing list
Conduit-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]