Re: [Evolution-hackers] Should I unref a CamelMesageInfoBase?
Hey On Wed, 2005-12-07 at 13:25 +0100, Jules Colding wrote: Hi, Must I unref a reference to a message info when retrieved by camel_folder_summary_uid()? This function increases the refcount before returning it. Yeah. you need to unref it. I can see from gw_update_summary() in the GroupWise provider that it never unrefs the reference. Is that wrong? few issues in the branch. The HEAD has all the fixes in. Cheers, partha ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Re: Questions about merging evo/e-util/e-util.c into e-d-s/libedataserver/e-util.c?
on 2005-12-21 klockan 10:45 + skrev Ross Burton: I've not looked at the source, but what does e_gettext() do that the i18n functions in glib/gi18n.h doesn't? Well, e_gettext() calls bindtextdomain(E_I18N_DOMAIN, EVOLUTION_LOCALEDIR) and bind_textdomain_codeset(E_I18N_DOMAIN, UTF-8) the first time it is called. I don't think any GLib functionality would take care of that? OTOH, those calls could well be taken care of by the appropriate main program, i.e. shell/main.c. And actually, surprise surprise, there already are calls bindtextdomain (GETTEXT_PACKAGE, EVOLUTION_LOCALEDIR) and bind_textdomain_codeset (GETTEXT_PACKAGE, UTF-8) there. Presumably the E_I18NDOMAIN in evo/e-util/e-util.c is the same as GETTEXT_PACKAGE in main.c? Could uses of e-i18n.h be replaced by, eh, gi18n.h? e-i18n.h include also gnome-i18n.h. what role does that play? Does the fact that Evo HEAD should be buildable against GLib 2.4 (and whatever is the corresponding old GNOME version) confuse issues any further? Argh, this mess is so weird... Is it just legacy code from the days before decent i18n in glib? Sure. --tml ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Re: Questions about merging evo/e-util/e-util.c into e-d-s/libedataserver/e-util.c?
On Wed, 2005-12-21 at 11:08 +, Tor Lillqvist wrote: on 2005-12-21 klockan 10:45 + skrev Ross Burton: I've not looked at the source, but what does e_gettext() do that the i18n functions in glib/gi18n.h doesn't? Well, e_gettext() calls bindtextdomain(E_I18N_DOMAIN, EVOLUTION_LOCALEDIR) and bind_textdomain_codeset(E_I18N_DOMAIN, UTF-8) the first time it is called. I don't think any GLib functionality would take care of that? OTOH, those calls could well be taken care of by the appropriate main program, i.e. shell/main.c. And actually, surprise surprise, there already are calls bindtextdomain (GETTEXT_PACKAGE, EVOLUTION_LOCALEDIR) and bind_textdomain_codeset (GETTEXT_PACKAGE, UTF-8) there. Presumably the E_I18NDOMAIN in evo/e-util/e-util.c is the same as GETTEXT_PACKAGE in main.c? Could uses of e-i18n.h be replaced by, eh, gi18n.h? e-i18n.h include also gnome-i18n.h. what role does that play? Does the fact that Evo HEAD should be buildable against GLib 2.4 (and whatever is the corresponding old GNOME version) confuse issues any further? gnome-i18n is deprecated and replaced with gi18n.h in Glib, so that isn't a problem. glib/gi18n.h (Evo) and glib/g18n-lib.h (EDS) were added in Glib 2.3.1, so that isn't a problem either. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
