RFC : Proposal for new simple GTK2-based DIA API [was Re: Dia Python]

[James Michael DuPont <mdupont777 yahoo com>]

--- Hans Breuer <Hans@Breuer.org> wrote:

> >If there's also a perl plugin coming up, we'll
> >need to encapsulate these things differently, so they behave the
> same
> >between main program and plugins.
> >
> There is nothing which can be done in Perl which can not be done
> in Python but readable. Not to start language wars but do we
> really need another language binding if we lack resources to 
> maintain one?

yes we lack resources, but not will power. 

> 
> So many people with bright ideas, so many vapor ware ...

Yes hans, almost all of my ideas about DIA are vapor right now.

This is directly related to the work I have been putting into the gcc
interface. We have just released a version for testing 
http://freshmeat.net/projects/introspector/

The issue of bindings is difficult, but in the end after some
discussion, I have come up with the following idea, please comment.

1. OAF/Bonobo : this is a fat API that supports costs more than we need
for scripting and interprocess communication.

2. GObject2 / GTK : this is the interface we need to script, and
we can base those scripting interfaces on a standard. For example the
GTK2 has a set of perl bindings in the works
http://sourceforge.net/projects/gtk2-perl/

I think that the best way forward is to define a new API for dia,
and then start factoring the code from the app back underneath it.

Here are the classes that i would like to see :

1. application
2. diagram
3. element
4. connection

each of them will support the idea of multiple views, and controllers.
each class will be derived from a "viewable" object and "controllable"
object. They will be responsable for the updating of the views
attached, and the dispatching of the changes, and the undoing.

and with "types"

1. application type
2. diagram type
3. element type
4. connection type

each type will allow a specialization of dias behaviour and the
subclassing of the application would allow for new versions of dia to
be  created. 
The types can of course be dynamic, and just support the ability to
save themselves to a file. So you can create a "prototype" out of an
instance, by drawing a element, and then converting that to a type. 

with the major relationships
application has collection of diagrams

diagram     has collection of elements
diagram     has collection of connections

connection  has a two elements
connection-class has many instances, each pointing back

element     has a collection of connections
element     has a indirect collection of other elements associated
element-class has many instances, each pointing back

a view has many objects (applications diagrams, elements, connections)
that are displayed.
a controller is connected to a object and dispatches messages to them
a message can be applied and undone. The resulting change to the object
can be undone my a memozation of the objects state before the change
was made.

the next step will be to allow this data to be accessed via the
redland/raptor api. That will also get a similar API as the system.
Then you can directly query the dataset via the rdf model.

In fact, the dia model translates directly onto rdf, where a connection
becomes a statement in rdf. 

These simple interfaces would be contain all the code from the GUI
that is needed to do all the work.

I think that they can be derived from the redland model, and that will
be the place that i will start converting to GTK2/GObject2 it supports
SWIG and via the swig we can generate a new set of bindings that
support a standard based API.

When the API is finished, i can then present it to you, and we can
start cutting out the code from DIA and shifting it into this new
model.

what do you think?
mike

=====
James Michael DuPont
http://introspector.sourceforge.net/

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com