Re: wysiwig TeX in dia

I think we are on the same wavelength.

I use Microsoft Visio 2000 and Sybase PowerDesignor at
work. PwrDsngr supports a meta-repository and has many
options to diff and merge models. Very powerfull.

Viso also supports a database repository.

The primary advantages of storing a diagram in
database become apparent
when the diagram is subject to collaborative
simultaneous use.  That's why
CAD and Information Engineering systems offer RDBMS
back ends.  

Yes, Even one user that has many tools hooked up to
the system. IE : Emacs, Source Code Parsers, CVS,
database structure extractors, layout tools, web

If several people can modify a diagram, I suppose up
to a point they could
use CVS or even just NFS <shudder> to keep
themselves synchronized.  But I
doubt the average Dia user is going to want to poke
around in the diagram
file looking for CVS's

   <<<<<<< diagram.dia
       version A
       version B 
   >>>>>>> 1.6

messages. :)
Powerdesignor supports diffing and patching modules in
a structured way. The XML file will be the best form
for that I think. The database can be extracted as a
log file and applied, but for merging, you need to mix
and match the changes.

The database's chief technical advantage is that
each shape can be stored
separately, so people can work on different parts of
the diagram without
getting in each other's way.  That doesn't avoid the
need for conflict
resolution, of course: a whole subsystem of
comparing/choosing/merging is
Yes, and such tools need good GUIs, and lots of work.
But are worth it.
It you describe the changes as individual XPATHs into
the document, they will be easy to compare.

Another advantage is reuse and reporting.  If you
want to find all the
diagrams for clients A and C that use shapes having
property X, it's
surely easier to write that query in SQL than C or
even Perl.  
Yes,and if you want to add in lots of annotations
attached to a diagram element, hrefs, documents, mails
and such. A database will be great.

Naturally, a shop full of Certified Dia
Professionals hammering away at a
giant collaborative diagram is light-years distant
from the "average Linux
end-user".  That doesn't make it a bad or pointless
And many people would welcome it.

Primed with suitable relaxant, it's possible to
imagine standardized
mapping of XML to relational databases, via a
Yes, I think we have be taking the same relaxant! 

For me a UML diagram is better than the DTD,
the introspector uses a meta-model to generate the
XML, Perl and SQL from. That meta model could be
edited and extracted from DIA. making it self hosting!

From there,
a standard library that stores and retrieves XML
documents using some
database driver technology.  

That would be much better than having a built in
database. Then you can use Perl or Java to do you
database interaction via a web service or pipe.

Then, Dia (or any other
application) could have the option of using a
filesystem or a database as
its data store.  That is, as long as the process of
serializing the
diagram to XML is kept separate from the process of
writing to the file.  
popen (X, "| perl")
fprint(X, XML DATA)
pclose (X)

I think that some form of API would be usefull to do
such interfacing. 
Do we have a dia diagram of the dia object model yet?
That would be a good start, to bootstrap the
Do you guys have anything against turning the DIA
sourcecode into XML via the introspector?

Then we can extract the various bits and peices and
try an generate a DIA diagram. What about C++toDia?
can that handled the Dia Source code?


James Michael DuPont

Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]