On Wed, Oct 29, 2003 at 11:54:42AM -0500, Jody Goldberg wrote:
On Wed, Oct 29, 2003 at 09:47:40AM +0100, Uwe Steinmann wrote:yup. open and probe are the only entry points.Implemented both. When is probe being called? Whenever a file is opened or only if one selects auto detection in the file open dialog?It is used when auto detecting file type. We first try to match by file name (to avoid loading the probe routine). If that succeeds we then do a content check via probe to see if things match.Ok. I added support for gsf to my library. Actually it's now prepared to use any kind of io access.great. All kinds via libgsf ? or via a wrapper to gsf.
I can tell the library which read, write, seek and tell functions to use. There is also a convience function which uses gsf_input_read(), gsf_input_seek(), ... by default.
1. My library can use external memory management functions instead of usual system functions. Does gnumeric provide memory management which I should use.Mostly no. There are some chunk allocators that we use for speed in places, but for the most part the stock glib g_* versions are what we advocate.
Ok, I will use those instead malloc, realloc, free.
2. The library can also call an external error handler. Same question as in 1.What sorts of errors ? The io_context passed into the reader is the best place to register warnings and errors.
All kinds of errors within the library, like not sufficient memory or passing bogus parameters to functions. In many cases it is probably ok to through the internal error message away and just do some more general error reporting. Though, i find it always useful to get an error msg from the place where the error actually occured. I guess I will have to extend my error handler with some pointer to user data, in order to pass the io_context.
3. Paradox files usually have some codepage xxx encoding. The library can do the conversions on the fly when accessing character fields. Should this be preffered opposed to gnumerics own recoding functions?I'll leave it to your discretion. We obviously have more experience with the glib variants, but you will have more domain experience on the format requirements.
Ok, I let the library to the recoding to UTF-8. Or maybe i check first, whether the library has recode support (which is hasn't if iconv or recode is not available) and fall back to glib if required.
4. I currently use value_new_string_nocopy(str), with str being a string allocated within the library. Should I rather use value_new_string(str) and free the memory allocated in the library afterwards?As long as the strings are being allocated with g_malloc/g_new type routines so that they can be freed with g_free then _nocopy is prefereable as it saves a needless alloc/copy/free cycle.
Ok, I'll tell the library to use g_xxx functions.
5. A paradox database is usually splitted into several files, e.g. a primary index is put into an extra file. In general it is not required to read those files, but it can accelerate access. Is there any way to access those files in a clean way from within the plugin?
...
When can we see the code ? It would be nice to get it in as soon as 1.3.x branches.
Do you just want to have a brief look into the plugin code or shall a send a patch to the current cvs? The patch will contain everything, changes to configure.in, po/POTFILES.in, plugin/Makefile.am, ... In order to test it, you will have to get pxlib from sourceforge. I have debian packages and could create untested rpms. Uwe -- MMK GmbH, Universitaetsstr. 11, 58097 Hagen Uwe Steinmann mmk-hagen de Tel: +2331 840446 Fax: +2331 843920
Attachment:
signature.asc
Description: Digital signature