On Fri, 12 Jan 2001, Hans Breuer wrote:
> At 17:02 12.01.01 +0800, James Henstridge wrote:
> >On Fri, 5 Jan 2001, Hans Breuer wrote:
> >> [...]
> >> 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.
> >
> obviously, but to me it looks much more appealing to write:
>
> width = r.right - r.left
> instead of
> width = r[2] - r[0]
or "(top, left, bottom, right) = r". And you can do the unpacking in the
argument list of a function. Eg:
def f(arg1, (t1, t2)):
pass
> >>
> >> 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?
> >
> Probably this would increase opportunities - I will look into it further.
> As far as I see it is just one more indirection (additional wrapping of
> data_render() ).
>
> Though this does *require* the additional parameter to the export function,
> to let the python plug-in distinguish which filter to use.
>
> My first non public version could have made the decision based on the file
> extension.
Hmm. The separation between diagram and diagram data should probably be
cleaned up a bit more at some point.
>
> >>
> >> 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.
> >
> Could you further look into it, to give me a clue what the implementation
> should look like ?
>
> >>
> >> - 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.
> >
> Both do allow at least one gpointer in the menu callback, right ?
> I thought of an Dia specific plug-in callback function with the
> following signature
>
> void plugin_cb (Diagram *dia,
> gint flags,
> gpointer user_data)
>
> Dia would than pass in the actual diagram or NULL and the flags parameter
> for e.g. interactive/noninteractive.
That sounds good. We just need code for actually inserting the menu item
into the menus that works with both gtk and gnome menus.
>
> On Dia's side there would be a simple procedurale database which gets
> called from either the gnome or the gtk menu callback.
>
> Additional it maybe useful to allow calling of the plugin_cb via a libdia
> call like:
>
> void dia_invoke_plugin (const gchar *name,
> Diagram *dia,
> gint flags)
>
> To register the plug-in callbacks something like:
>
> void
> filter_register_callback (DiaFilter *cbfilter,
> const gchar *name,
> const gchar *menu_path)
>
> would be used.
>
> >>
> >> - 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).
> >
> With some extra tweaking it is possible on win32 to export symbols from
> executables as well. Even the cross dependency could be resolved.
> But IMO the much cleaner way to do it is to not make the executable
> dependent on libdia *and* libdia (or other libraries like the python
> extension) dependent on the executable.
oh well. You are the win32 expert :)
>
> >>
> >> - 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.
> >
> I've thought of an implementation of the render api, but with the direction
> to Dia, let it create the appropriate object. This would simplify the
> process of writing an import filter, especially if there is already an
> export filter for the file type (do the same mapping in both directions).
>
> For advanced import filters a generic object creation mechanism should be
> provide. Create objects by name with default parameters and change the
> object paarmeters via the property api. The latter should probably be
> defered behind the "gobject-ification" of all the Dia objects.
>
> >>
> >> 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.
> >
> Thanks, I have added the files and Steffen had it hands on it, too. Maybe
> it is already working?
I will take a look at it.
James.
