Re: [Evolution-hackers] Rethinking account management
More brain dumping so this is all out in the open. Since I've been blathering on about this new ESource API and these "extension" things but haven't actually posted the API, I thought I should do so. Also attached are my notes for the GSettings schemas for these various ESourceExtension subclasses. Each subclass is really nothing more than a thin wrapper for GSettings keys from a particular schema. More detail about these later -- I'm still tweaking them. ESource === Properties: "backend" : gchararray(read/write) "file" : GFile * (construct-only) "name" : gchararray(read/write) "settings" : GSettings * (read-only) "uid" : gchararray(read-only) Signals:void (*changed) (ESource *source); Functions: GType e_source_get_type (void) G_GNUC_CONST; ESource * e_source_new(GFile *file, GError **error); guint e_source_hash (ESource *source); gbooleane_source_equal (ESource *source1, ESource *source2); voide_source_changed(ESource *source); const gchar * e_source_get_uid(ESource *source); GFile * e_source_get_file (ESource *source); GNode * e_source_get_node (ESource *source); const gchar * e_source_get_name (ESource *source); voide_source_set_name (ESource *source, const gchar *name); const gchar * e_source_get_backend(ESource *source); voide_source_set_backend(ESource *source, const gchar *backend); GSettings * e_source_get_settings (ESource *source); gpointere_source_get_extension (ESource *source, const gchar *name); gbooleane_source_has_extension (ESource *source, const gchar *name); ginte_source_compare_by_name(ESource *source_a, ESource *source_b); ESourceExtension Properties: "settings" : GSettings * (read-only) "source": ESource * (construct-only) Signals:(none) Class Data: const gchar *name; /* extension name */ const gchar *schema;/* GSettings schema */ Functions: GType e_source_extension_get_type (void) G_GNUC_CONST; ESource * e_source_extension_get_source (ESourceExtension *extension); GSettings * e_source_extension_get_settings (ESourceExtension *extension); ESourceRegistry === Properties: (none) Signals:void(*load_error) (ESourceRegistry *registry, GFile *file, GQuark error_domain, gint error_code, const gchar *error_message); void(*source_added) (ESourceRegistry *registry, ESource *source); void(*source_changed) (ESourceRegistry *registry, ESource *source); void(*source_removed) (ESourceRegistry *registry, ESource *source); Functions: GType e_source_registry_get_type (void) G_GNUC_CONST; ESourceRegistry * e_source_registry_new (void); ESourceRegistry * e_source_registry_get_default (void); voide_source_registry_add_source(ESourceRegistry *registry); voide_source_registry_remove_source (ESourceRegistry *registry); gbooleane_source_registry_load_sources (ESourceRegistry *registry, GError **error); gbooleane_source_registry_load_directory (ESourceRegistry *registry, const gchar *path, GError **error); ESource * e_source_registry_load_file (ESourceRegistry *registry, GFile *file, GError **error); ESource * e_source_registry_lookup_by_file (ESourceRegistry *registry, GFile *file); ESource * e_source_reg
Re: [Evolution-hackers] Rethinking account management
Here's a progress update on my account management rewrite. I've been on travel for the past three weeks and still have another week to go, so I've only been able to work on this in short spurts -- an hour here, an hour there. But I've managed to work through all of E-D-S, get the test-source-combo-box and test-source-selector programs working with the keyfile-based ESources, and am now plowing my way through Evolution itself. As usual this is turning out to be a bigger job than expected, and I'm less confident now that I can get this all done by 2.91.90 but I'm still gonna try. The alternative, since I -really- don't want these XML blobs creeping into GSettings even temporarily, is to depend on GConf for 3.0 and then land this stuff (along with Rodrigo's GSettings branch) early in 3.1. Were it not for the pressure to get everything converted in time for GNOME 3.0, I would already be retargeting this for 3.1. Overall the changes are having a simplifying effect on the code base, but it will introduce an API break of some kind to almost every library in E-D-S. That's what I wanted to talk about here. I'm still only on address books and calendars. For mail accounts, EAccountList will die and EAccount will be split into two separate key files (one for "store" settings, one for "transport" settings). Beyond that I don't anticipate many (if any) more API breaks in E-D-S for mail accounts. For address books and calendars, ESourceList and ESourceGroup will die (replaced by an ESourceRegistry singleton which holds everything). The ESource API will be rewritten from scratch, will no longer use GConf and also will no longer have a URI. All other API breaks follow from that. So here's what I've broken on my branch so far, grouped by library: libedataserver -- - Remove ESourceList and ESourceGroup. - Rewrite ESource from scratch. 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(). - ECalAuthFunc: the 'key' argument is no longer used. libedata-cal - Remove e_cal_backend_get_uri(). libedataserverui - All e-passwords functions will simply take an ESource instead of "component" and "key" strings. Keyring entries will contain the UID of the corresponding ESource instead of URI components (we'll convert existing keyring entries as part of the migration phase). - ESourceComboBox will take an ESourceRegistry and an extension name as constructor arguments. The given extension name will filter the sources shown in the widget (e.g. "address-book", "calendar", etc.). - Similarly for ESourceSelector. ___ 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.32.1 build error
On Thu, Dec 9, 2010 at 8:46 AM, Thomas Mittelstaedt wrote: > Am Mittwoch, den 08.12.2010, 14:37 +0100 schrieb Sasa Ostrouska: >> On Wed, Dec 8, 2010 at 2:10 PM, Thomas Mittelstaedt >> wrote: >> >> >> libevolution_a11y_la-gal-a11y-util.lo `test -f 'gal-a11y-util.c' || >> >> echo './'`gal-a11y-util.c >> >> mv -f .deps/libevolution_a11y_la-gal-a11y-util.Tpo >> >> .deps/libevolution_a11y_la-gal-a11y-util.Plo >> >> make[2]: *** No rule to make target `../e-util/libeutil.la', needed by >> >> `libevolution-a11y.la'. Stop. >> >> make[2]: Leaving directory `/home/sasa/evolution-2.32.1/a11y' >> >> make[1]: *** [all-recursive] Error 1 >> >> make[1]: Leaving directory `/home/sasa/evolution-2.32.1' >> >> make: *** [all] Error 2 >> >> s...@quadser:~/evolution-2.32.1$ >> >> >> >> Any ideas ? >> >> >> > >> > Try run autoconf again. See also: >> > http://mail.gnome.org/archives/evolution-list/2010-November/msg4.html. >> > >> > Hope that helps, >> > >> > -- >> > thomas >> >> thomas, thanks, I looked at the message and it doesnt suggest me >> anything. I have also tried to >> do an autoreconf -ivf but it doesn't help. > > It "suggests" to you to try a clean setup from scratch. See if that > works. Create a fresh src directory, check out the sources, create that > object dir as outlined in the above message, install the software into > a clean directory like /opt/evo and then see if that still gives you > errors. See also the follow-up message, > http://mail.gnome.org/archives/evolution-list/2010-November/msg5.html. > Ok thomas, will try that. Thanks for now. Rgds Saxa ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
