Re: Shapes layout proposal

[John Palmieri <johnp martianrock com>]

Lennon Day-Reynolds wrote:

> 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.
> (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?

> Basically, I see the shape definition syntax as an extension of the
> current custom shapes code to allow the attachment of addtional
> properties that may or may not have any direct visible rendering, but
> are exposed via the 'mini-DOM' to C or scripting code that gives the
> objects their complex behavior. All of the I/O can be handled by the
> standard XML library, and the object interfaces can just be a deifned by
> a handful of callbacks, which are based on an event/listener model.

Again I think we are getting ahead of ourselves with callbacks.  Such things
like what the callbacks should pass have not been discussed and should not
be until we get the basic layout working.  I think default behaviors such as
layout and resizing that work on a shape as a whole should be worked on
first with event/listeners being added for more custom layouts (i.e. the
ability for an object to listen for another object resizing and resize
itself accordingly). Event listeners would just complicate getting things
off the ground quickly.  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.

> The subtle difference between this and the current custom shapes only
> become apparent when this behavior-modifying code is present; the
> remainder of the time, they will simply be rendered just like the
> current SVG-based custom objects, with their properties editable via the
> standard mechanisms. This also means that a user opening a diagram with
> these object types will only need the XML definition to read them, not
> the C/Python/whatever behavior code. Believe me, this is a good thing --
> an XML file is very portable, and very easy to distribute, compared to a
> .so or .DLL file.

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.

> As to C++ being the implementation language, I'm going to have to second
> Andre and whoever else balked at it: we want to interoperate with Dia,
> not replace it. For example code, we have several sources: the
> standalone Dia Canvas available from GNOME CVS or SourceForge, the Gill
> SVG-viewer project, and the Sketch vector editing program (which has the
> further advantage, to my mind, of being almost entirely written in
> Python, with a few C libraries to handle performance-intensive things
> like rendering and event dispatching).

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...

> Lennon Day-Reynolds
>
> _______________________________________________
> Dia-list mailing list
> Dia-list gnome org
> http://mail.gnome.org/mailman/listinfo/dia-list

--J5