Re: supporting unlisted calendar source uris

After a bit of testing I have committed your patch. I renamed the open_from_uri method to be more consistent but otherwise your stuff looks OK.

Out of interest, what sort of app are you building?


On 7/1/07, Thomas Viehmann <tv+conduit-list beamnet de> wrote:
Hi John,

thank you for your comments.

John Stowers 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?
Basically, I want to access and manipulate several calendars not
installed in evolution on a computer that doesn't have evolution
(only eds).

> 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?
Appearantly not unless the location is registered.

> 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.
OK. I've tried to match evo_cal_source_open_source (and copied most
of it) with evo_cal_source_open_new_with_absolute_uri.
This is the attached patch evolution-python.source_new.diff.

Additionally, I've tried to add some ECalComponent methods for due
dates, categories, priorities, and url.
This is the attached patch evolution-python.ecalcomponent.diff .

I'm afraid that it shows that I'm neither an expert at writing python
extensions nor have I wrapped gnome libraries before, but I hope that
I don't have to many routes to SIGSEGV in it. Maybe some parts are
even useful.

Kind regards

Thomas Viehmann,

Conduit-list mailing list
Conduit-list gnome org

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