Re: [Gnome-devtools] What we're doing.

[Andrew Sutton <asutton21 home com>]

> Dia has a plugin mechinism, that might be sutible to use. If it is not
> possible to do what we want with Dia, I'm sure it would at least be a
> good base.

i've been thinking about this the last 3 weeks now... how to build a uml
modeler without doing anything new. using dia definitely crossed my
mind. i also thought it would be really cool to base it of SVG. then it
can be displayed in any SVG compatible browser - or some component that
does that. but that's implementation. i'm still looking at
technologies...

> Yeah, an XML format would be desirable. Dia uses an XML format, and from
> breifly looking at one of my class diagrams, I don't see any trouble
> with using it. And, as an added bonus the data would be
> editable/viewable in Dia. You are right that a design tool should have
> it's own data model, ideally this would listen to the source model and
> incorperate valid edits. As for code generation, the basic requriement
> is that it should recognize existing structure in the source, and make
> the minumum number of changes for source to match the model. Style
> sheets may be the proper method, I'm not sure, whatever method used
> would probably use gpf to recognize existing structure. This is the part
> of code generation that currently suffers, from what I've seen (for
> example glade).
> 

just curious? what does gpf stand for and what does it (or is it going
to) actually do? it is the intended central component right? the
organizing factor (or something like that?)

if it's possible, you could use gpf (if it does what i think its
supposed to) to collect and negotiate between different parts of the
design process. it's easy to think about design and implementation here
with the uml->code type stuff. gpf can keep a list of classes or modules
that can be either affected through the design tool or the source
editor. then, you can just notify the other tool that something has
changed - ah... good use for the corba event service :)

actually you could build all kinds of tie ins to that. like requirement
tracking mapping to test test plans, project files onto source control,
etc. etc. whatever we can think to build tools for. that's neat.

> 
> That would be very good, as with the other components it should probably
> have a corba interface to fit in with the rest of the framework.
> 

you mean people would not want to write components? ;)

Andrew Sutton
asutton21 home com