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]
though in some cases the tuple represantation would be useful as well. Do
you know a way to have both - in the same object ?
>>
>> (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.
>
Fine (it is in cvs already).
>>
>> 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.
>>
>> 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.
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.
>>
>> - 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?
Regards,
Hans
-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to
get along without it. -- Dilbert
