> > John/James L./Andre: > > > > I like (and have argued for) the idea of a 'mini-DOM' API, based on a > > subset of SVG, being used as the internal structure of these Ur-Shapes. > > For the arbirary additional properties, we need a portable, > > language-agnostic set of datatypes, which can come from XML Schemas. Agreed. I have read some docs about them and I like XML Schema. The only problem here is that we have no Schema-validating parser. > > (Note: the types in the schema spec are acutally fairly close to those > > in the Dia std. props library, with the exception of the UI elements, so > > much of the code can probably be adapted from there and/or made to work > > with std. props objects). > Can you give me a URL to the Schema specs? www.w3.org/XML/Schema should do the trick, much resources linked from there. > > [Callbacks...again] > Again I think we are getting ahead of ourselves with callbacks. Yeah, let's first do the stuff we need to get the thigs on screen, then we can do customization/specialization stuff. > I think the custom shape code should be used as a reference but > since we would be gutting the internals anyway, a new object > should be created from scratch possibly using some of the shape > code. I would like to add it as a drawing primitive of dia-canvas > since that is where dia seems to be moving. Agreed. I think us doing the coding from scratch is easier than thinking into the custom shape code. > [no difference to the end user?] > The internals are going to be different to accommodate layout and > properties. A mini-DOM interface will be added along with any classic > interface that needs to be present for dropin compatibility. Hmm, I think > external .so's .dll's and python scripts would be a good thing. In most > cases the behavior code would be specific to editing in Dia but one could > take a diagram, bind a new script to it and create a completely new > program. For example a program that takes a circuit diagram written in Dia > and runs a simulation on it. As for portability that would be up to the > author of the callback libraries. Again that is all future work. That's what I want to do with ConStruct. (http://con-struct.sourceforge.net) But I'll keep the interpreter outside of Dia. That's what I need the parsing stuff for. > [C++?] > I don't think C++ will be the implementation language I just think James > needs to think in C++ terms to understand the problem at hand. I will > convert that to UML and all will be right in the world. I think using some > code from Gill and/or Sketch would be nice for the SVG parsing so that we > might be able to support most of SVG. Like I have stated before I think > having the ability to use the full SVG spec allows people to import complex > objects when appropriate. Right now we are going to stick with a subset for > simplicity but in the future... I never balked at C++ being the language of choice. I am comfortable with C, even if in an object-oriented manner of coding. As for using more of the SVG specs, this is outside my bounds. > > Lennon Day-Reynolds > --J5 cu Andre -- Tolerance rulez, everything else sux! -- Andre Kloss _______________________________________________ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list
