Re: [Evolution-hackers] Evolution.Contact.Set(ContactField field, IntPtr value)
Hi Marcus, On Sat, 2007-09-29 at 10:03 +0200, Marcus Krantz wrote: Hi all, I'm playing around a little bit Evolution-sharp. Since .NET is all new to me I have some problems setting fields of contact instances. I would really like to use the Set function but when I try I get compilation errors all the time. Consider the following snippet: Contact c = new Contact(); ContactAddress addr = new ContactAddress(); IntPtr i = Marshal.AllocHGlobal(Marshal.SizeOf(addr)); addr.Country = Sweden; addr.Street = Test; addr.Code = SE-123 23; addr.Region = Gothenburg; c.Set(ContactField.AddressWork, addr);// CS1503 c.Set(ContactField.Email, [EMAIL PROTECTED]);//CS1503 Marshal.StructureToPtr (addr ,i, false); c.Set(ContactField.AddressWork, i); You need to free the allocated memory. This may help : http://www.mono-project.com/Interop_with_Native_Libraries Regards, Johnny ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Synching Evolution/GNOME version
Hi Matthew, On Thu, 2007-10-04 at 10:00 +0530, Srinivasa Ragavan wrote: And while we're at it, can we please drop the meaningless -1.2 suffix from the library names (e.g. libedataserver-1.2.so)? As far as I can tell this is just an artifact from an age before the EDS sonames were properly versioned. Cue, screaming ... please read: http://lxr.go-oo.org/source/dba/connectivity/source/drivers/evoab2/EApi.cxx#046 and reconsider ;-) be aware that it takes weeks to months to get that change up-stream, and months to get a new version of OO.o out, and all the while OO.o will ~silently fail to work with people's new 'clean' renamed library e-d-s :-) AFAIR the name versioning was originally intended to ensure you could compile develop multiple versions of evo. on the same system. I don't think those application would be happy to do this. There are a few apps that use the .so directly without pkgconfig (iirc OpenOffice.org). Quite - we build our OO.o integration (which since it is up-stream has to run on ~all existing systems - cf. the ISV problem ...), with internal headers (to unwind the ABI breakage), and explicit dlopening hooking out of symbols etc. Unless there is a clear nod from the stake holders of those projects, I wouldn't be favor of doing this. Thanks ! :-) Of course, as long as the dlopens still work, I'm fine with renaming the core library (to suit people's personal hygiene issues) as long as we have a compat symlink in perpetuity ;-) Thanks, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Synching Evolution/GNOME version
On Thu, 2007-10-04 at 10:05 +0530, Srinivasa Ragavan wrote: Even I would have loved this if we can get all the friends to be 2.22. Unfortunately GtkHTML can't be 2.22 as it is already 3.xx. I felt that synchronizing the minor versions is fine. I'm not really against it, if there aren't any major objections to this. I'm fine with GtkHTML being switched to 3.22, but I think it should be the only exception, EDS should jump to 2.22. No point not syncing it entirely when its possible. 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 signature.asc Description: This is a digitally signed message part ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] EBook query string format?
Hi, Does anyone know the format of the query string in EBook functions such as e_book_backend_db_cache_get_contacts()? Naturally I can start digesting e-book-backend-sexp.c but I would rather not... Thanks, jules ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Patch that fixes compilation warnings on iconv-detect.c
These compilation warnings prevent -Wall -Werror as the configure stage fails if CFLAGS is set that way. http://bugzilla.gnome.org/show_bug.cgi?id=483301 -- Philip Van Hoof, software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://www.pvanhoof.be/blog ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Synching Evolution/GNOME version
On Thu, 2007-10-04 at 09:57 +0100, Michael Meeks wrote: Cue, screaming ... please read: http://lxr.go-oo.org/source/dba/connectivity/source/drivers/evoab2/EApi.cxx#046 and reconsider ;-) be aware that it takes weeks to months to get that change up-stream, and months to get a new version of OO.o out, and all the while OO.o will ~silently fail to work with people's new 'clean' renamed library e-d-s :-) Oye, I wasn't aware of the pain involved. Thanks Michael and Srini for clarifying this. At least now it's on record for the next time someone has the same bright idea. :) Matthew Barnes ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
