Re: [Evolution-hackers] Rethinking account management
On Mi, 2011-01-26 at 11:34 -0500, Matthew Barnes wrote: > Can you elaborate on the creation use case? Sounds like you're creating > local data sources on the fly? Yes. The primary use case is in automated testing. Instead of having to create the database in advance via the GUI, the test driver does it automatically. I've also heard of users who read and write .ics files in arbitrary locations by using the calendar backend with a file:// uri. These are KDE users who then read and write these files via KOrganizer - a bit crude, but usable. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evolution 2.91 now requires gtk+-3.0
On 01/26/2011 07:37 PM, Matthew Barnes wrote: As of today, we have dropped support for gtk+-2.0. Evolution and all related modules now require gtk+-3.0. Until the GTK+ team releases version 3.0, I'm going to keep our gtk+-3.0 requirement set to the latest tarball release -- currently 2.99.2 -- to ensure we're all keeping up with the latest bug fixes. Once Evolution 3.0 is released, we'll be back to our usual policy of requiring only stable libraries. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers Congratulations people. You rock! ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Evolution 2.91 now requires gtk+-3.0
As of today, we have dropped support for gtk+-2.0. Evolution and all related modules now require gtk+-3.0. Until the GTK+ team releases version 3.0, I'm going to keep our gtk+-3.0 requirement set to the latest tarball release -- currently 2.99.2 -- to ensure we're all keeping up with the latest bug fixes. Once Evolution 3.0 is released, we'll be back to our usual policy of requiring only stable libraries. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking account management
On Wed, 2011-01-26 at 16:23 +0100, Patrick Ohly wrote: > SyncEvolution uses all of these calls. I don't mind rewriting the code, > but let's make sure that there is a proper replacement. > > What I need to do is: > - list all address books and calendars > - open any of the listed databases > - create new ones at a location chose by the user > (file:// uri in the current API) > > Is all of that still going to be possible? How? Listing calendars will look something like this: #include #include #include ESourceRegistry *registry; const gchar *extension_name; GList *sources; registry = e_source_registry_get_default (); /* List all calendars. */ extension_name = E_SOURCE_EXTENSION_CALENDAR; sources = e_source_registry_list_sources (registry, extension_name); /* Do something with the list of ESource objects. */ g_list_free (sources); Other extension names include: E_SOURCE_EXTENSION_ADDRESS_BOOK E_SOURCE_EXTENSION_MEMO_LIST E_SOURCE_EXTENSION_TASK_LIST No change to the way ECal and EBook objects are opened. Can you elaborate on the creation use case? Sounds like you're creating local data sources on the fly? ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking account management
On Do, 2010-12-09 at 11:00 -0500, Matthew Barnes wrote: > libebook > > - Remove e_book_new_from_uri() and e_book_get_uri(). > > - Remove e_book_get_addressbooks(). > > > libecal > --- > > - Remove e_cal_new_from_uri() and e_cal_get_uri(). > > - Remove e_cal_get_sources(). I must admit that I haven't read all of the emails due to lack of time. SyncEvolution uses all of these calls. I don't mind rewriting the code, but let's make sure that there is a proper replacement. What I need to do is: - list all address books and calendars - open any of the listed databases - create new ones at a location chose by the user (file:// uri in the current API) Is all of that still going to be possible? How? -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
