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

[Lars Clausen <lrclause cs uiuc edu>]

On Fri, 17 Jan 2003, James Michael DuPont wrote:
> --- Lars Clausen <lrclause cs uiuc edu> wrote:
> > On Thu, 16 Jan 2003, James Michael DuPont wrote:
> > > --- 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
> > > [...]
> > > what do you think?
> >
> > I think you should look a little more at the current Dia structure. 
> > While
> > it bears some resemblance to what you describe above, it's different
> > enough
> > that it would be an unnecessary pain to change it.  I really don't
> > see the
> > need to change the Dia API like that.
>
> Well, I will review the differences, as far as I can tell, 
> does the current API does have a clean separation between the
> implementation and the inteface? 

Yes it does.  The diagram structure is separate from the rendering
structure is separate from the interface.  Please familiarize yourself with
the code before suggesting mass changes -- adopting a new API like that
would require changing every single object, a major and bugprone project
just to change API arbitrarily.  If you have some arguments why your API is
better than the current, please tell us.

> Plus I would like to have a clean model for scripting. It will be
> easier to aggree on a simple new model, and modify existing code to
> work with it than to try and upgrade the existing. 

No, it'd be easier to agree on a simple old model that's already
implemented and has been working for many releases.

> > I have no idea what the redland/raptor api is.
> redland is a rdf application framework :
> http://www.redland.opensource.ac.uk/
> here is the readme 
> http://www.redland.opensource.ac.uk/docs/README.html

Hm.  I will consider this YATLA until I see code with it.  

-Lars

-- 
Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| Hårdgrim of Numenor
"I do not agree with a word that you say, but I   |----------------------------
will defend to the death your right to say it."   | Where are we going, and
    --Evelyn Beatrice Hall paraphrasing Voltaire  | what's with the handbasket?