Re: Provide a python script to dia on the command line

[Martin Metzker <martinmetzker gmx net>]

Hello list!

I think I have a viable patch now, for command line provided python 
scripts in dia. Going over the changes:
> > ... moved the definition of struct _PluginInfo from lib/plug-ins.c to
> > lib/plug-ins.h, because I need this struct in app/app_procs.c.
> not ok. To avoid this please use dia_plugin_get_symbol().
Using dia_plugin_get_symbol() and dia_plugin_get_name() now. No changes 
to lib/plug.ins.{c,h} anymore.

> > ... modified app/app_procs.c app_init() to include the -i option and 
> > stores
> > the provided filename in a local variable python_script.
> ok, though I would prefer another short option, maybe -r and 
> --run-script instead of --python?
Done.

> > ... added a block if(python_script) which checks if the python 
> > plug-in is
> > loaded, and does run_script_oneshot(python_script) when sensible.

Extended functionallity: run_script_oneshot() still exists as described 
and is still being used during initialization. For running the script 
provided via the command line, there is now run_script_w_context(), 
which makes the variables files, export_file_name, export_file_format, 
input_directory and output_directory accessible from within python. To 
accomplish this, the code block in app/app_progs.c creates a GHashTable 
with these variables (files is collapsed to a ,-separated list), which 
is passed to run_script_w_context(), which propagates the information to 
the python interpreter before calling run_script_oneshot().

> IMO the patch is not too big to be discussed (and finally be applied) 
> in one piece.
I would be happy if that is still the case.

> There are minor coding style glitches (tab size, placement of braces) 
> but I can fix these before commiting.
I modified all the code I touched. There seems to be a little 
inconsistency with indentation. I kept to the dominant style of 
app/app_progs.c which is 3 spaces for function bodies and an additional 
2 spaces for each {. My code layout should be at least consitently broken.

In addition, at its very beginning, this patch includes

-      ef->export_func(diagdata, ctx, outfname, infname, size);
+      ef->export_func(diagdata, ctx, outfname, infname, (void *) size);

which fixes a compile warning that kept annoying me.

Cheers

Martin

Attachment: dia_python_with_context.patch
Description: Text Data