Hello Michael, > Frank - I'm assuming here that it's ok to directly link to the glib API > - splitting that out would be an even bigger pain, and I believe that's > a platform pre-requisite for OO.o now.
According to Heiner Rechtien: No way. His points are - we're developing C++, not C, so what do you need from this lib what isn't (semantically equivalent) available elsewhere? - glib has just recently been removed - the only thing still depending on it is the Gnome integrator. RE would be quite unhappy with re-introducing it. - an architectural change such as this (one of the libs depending on glib) needs approval by at least Matthias Huetsch (and is unlikely to get it) - This would create yet another "version hell", if we'd do this. So I fear we need to find another solution :( What kind of code do you need from glib? > d) call EApiInit() as early as we can at a well defined > point before we use any e_ API > e) throw an exception if that init fails I suggest the driver, which is the initial entry point, anyway. It would do an EApiInit in it's first |acceptURL| or |connect| call. In the first case, it could silently return sal_False if the init fails, in the latter, it could throw an exception. > JP - since you're ultimately responsible for the gratitous ABI breakage Thanks & Ciao Frank -- - Frank Sch�nheit, Software Engineer, OpenOffice.org Database Access - - [EMAIL PROTECTED] http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - _______________________________________________ evolution-hackers maillist - [email protected] http://lists.ximian.com/mailman/listinfo/evolution-hackers
