Camel hackers, It's not clear from the gtk-doc API documentation* whether or not you must unreference a store after getting it using camel_session_get_store
*) http://pvanhoof.be/files/libcamel-api/html/CamelSession.html . . . Actually, it's not clear for most CamelObjects whether or not you should do that. I have filed multiple bugs about this already. But it really looks like the "very few people care"-phenomena or the totally wrong "it works for Evolution so it's not broken"-thinking is happening here: No replies, not even a bug confirmation or marking the bug as invalid. Some bug examples (they might be outdated or wrong, I stopped checking them and started implementing workarounds because I simply can't wait for months for such bugs to be looked at). http://bugzilla.gnome.org/show_bug.cgi?id=343882 http://bugzilla.gnome.org/show_bug.cgi?id=343683 I would also like to point out that Camel often crashes on the check_magic method for CamelObject types that you implemented yourself (like the CamelSession implementation you have to provide to Camel). This check_magic method seems to happen each time you do the macro casting: CamelSession *session = CAMEL_SESSION (thingy) CamelSession *session = (CamelSession*) thingy, however, works perfectly. Debugging sessions, however, revealed that the instance "thingy" is healthy and fully correct. It also seems to be a race condition or at least something that doesn't always happen. Making me wonder: Why not simply replace CamelObject with GObject? And what is this "check_magic" thing anyway? It seems to loop over a inheritance tree or something like that. -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be _______________________________________________ Evolution-hackers mailing list [email protected] http://mail.gnome.org/mailman/listinfo/evolution-hackers
