On Fri, 5 Jan 2001, Hans Breuer wrote:
> Hi James et al,
> with my recent additions to the Dia Python Plug-In it is possible to write
> export filters completely in Python.
>
> --Example.py
> import sys, dia
>
> sys.argv = [ 'dia-python' ]
>
> class Renderer :
> def __init__ (self) :
> pass
> def begin_render (self, data, filename) :
> self.f = open(filename, "w")
> self.f.write("Extents: "+ str(data.extents) + "\n")
> self.f.write("file: "+ filename + "\n")
> def end_render (self) :
> self.f.close()
>
> dia.register_export ("PyDia Export Example", "diapye", Renderer())
>
> -end example.py
>
> There are two kinds of filter implementations possible:
> - Implement a renderer : The Python class needs to implement each
> required renderer function like draw_image(), draw_string() etc.
> See export-render.py
This looks great.
>
> - Implement an object filter : Only begin_render() and end_render()
> need to be implemented. Iteration over the Diagram Objects is totally
> done by the filter. This one may finally (e.g.) allow to write a
> Source Code generator for UML diagrams in an appropriate language ...
> See export-object.py
>
> The main part of the work was adding more object wrappers to the
> language binding. They are:
>
> DiaExportFilter, DiaDiagramData, DiaPoint, DiaRectangle, DiaBezPoint,
> DiaFont, DiaColor, DiaImage, DiaProperty, DiaProperties, DiaArrow
Some of these things probably don't need a new python type. For instance,
a DiaPoint can easily be represented by a tuple of 2 floats. Probably the
same for rectangle, bezpoint and a few others.
>
> (see the attached export-*.py examples, to how they are used)
>
> Changes required to the Dia core:
> ---------------------------------
> The Dia<Ex/Im>port interface needed a provision to run different
> filters via one callback function. I've added an additional user_data
> field to the Dia<Ex/Im>port struct and let it be passed to the
> export() / import() function as additional parameter.
I was thinking of adding that, but didn't get round to it. May be useful
for other things as well.
>
> By this the Python extension is able to distinguish which renderer
> class needs to be called.
Would it be better to just register a function as the export filter,
rather than just a renderer object? And let that function call the
render method of the diagram, maybe?
>
> Additional changes I would like to add/make:
> --------------------------------------------
>
> - extend the property API to allow Properties, which are themselves
> lists of properties. This would be required to make the UML module
> really useable from Python. But I'm not sure about the appropriate
> implementation
Well, the properties API is not frozen, so it can be extended as needed.
>
> - add register_menu_function () to allow to implement even generic
> plug-ins in Python or any other language callable by C code.
We will need to make sure this works with both the gtk and gnome based
menus.
>
> - move some code from the Dia executable to libdia, which may finally
> lead to a Python extension, which does not require to be embedded in
> Dia. At the moment it would clean up some nastyness required to
> make these functions and variable callable from Python. The current list
> of code to move (see app/dia.def) :
>
> Additional the GSList* open_diagrams should be moved to libdia.
Is this actually necessary? On linux, you can pass the --export-dynamic
flag to the linker that allows dlopen'ed libraries to use the symbols in
the main executable. Can a similar thing be done on windows? (I assume
libtool must do that to handle the -export-dynamic flag under windows).
>
> - implement a more generic Import API, which should allow simplier
> diagram construction from files and may finally allow round-trip
> engineering ...
import needs work. I have been thinking about how easy it would be to
provide simple function to create objects of the standard types.
>
> If noone objects I'll commit the first chunk of PyDia changes
> to cvs. Is there anyone out there who would do the required
> makefile.am changes ?
I can make the changes to the makefile.am. They will probably be trivial
though.
>
> Enough for now. Any objections, hints, flames, whatever ?
>
> Have Fun,
> Hans
James.
