--- Hans Breuer <[EMAIL PROTECTED]> 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 _______________________________________________ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.lysator.liu.se/~alla/dia/faq.html Main page at http://www.lysator.liu.se/~alla/dia
