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

[James M. D. <mdu...@ya...>]

dear fellow hackers,

you will find my proposal for a new GUI api that uses the redland model
as its basis. 

This will involve a new mixture of gtk2, inline, and swig to try and
create a single definition and support multiple interfaces. 

I think that dajobe is on the right track with swig, and that should be
expanded apon to support the new gtk2 interfaces. Inline has been
experimental support of Swig. The next set is to layout a set of rules
for creating a standard gnome-like scripting api. 

mike

--- James Michael DuPont <mdu...@ya...> wrote:
> From: James Michael DuPont <mdu...@ya...>
> Subject: RFC : Proposal for new simple GTK2-based DIA API [was Re:
> Dia Python]
> To: dia...@gn...
> List-Subscribe: <http://mail.gnome.org/mailman/listinfo/dia-list>,
> List-Archive: <http://mail.gnome.org/archives/dia-list/>
> Date: Thu, 16 Jan 2003 22:25:50 -0800 (PST)
> Content-Length: 1959
> 
> 
> --- Hans Breuer <Ha...@Br...> 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
> Dia...@gn...
> 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
> 


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

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