Re: Shapes layout proposal

[Lars Clausen <lrclause cs uiuc edu>]

On Thu, 14 Jun 2001, James K. Lowden wrote:

> Cyrille Chepelov wrote:
>
> >  if you show me a shiny new dia core, with DOM as its kernel, and the
> > resulting stuff is not only as featureful (including all current object
> > types) as the "classic" dia of then, but also naturally is able to
> > reload older files (though it might be through an incomplete translation
> > layer), and all that with decent speed on my 32-MB P133, then I shall
> > bow, eat my words, and adapt.
>
> Cyrille (and: Lars, Lennon, John),
>
> I'm not sure I'm reading the heat/light ratio of this discussion
> correctly, but as someone interested in the furtherance of Dia and
> willing (if unprepared) to help bring greater semantic meaning to its
> files, I want to say I'm not willing to start by drawing a line in the
> sand saying "Stand well clear".  I want to work with you, Cyrille,
> because you're doing good work and a lot of it, and because you
> consequently understand issues I don't.  While I don't think John was
> gunning for the Nobel Peace Prize, he gets credit to my mind for starting
> an interesting commotion, at least, nes pas?

I apologize for getting into flame mode.  Kloss' other mail is a far cry
from the "let's redo everything in XML" impression I had.  

[...]
> My idea is a simple one: to have user-defined text fields in a shape.
> There should be some notion of an array of such fields (my eye is on
> database table definitions), and the shape should adapt its height and
> width to display the enclosed rows text fields.  

This sounds very nice indeed.  Nothing I can say against that.

> John's idea is more ambitious.  I'm not saying it's wrong or right or
> better or worse or brilliant or nuts, only that it's more.  So let me
> ask: Is it your assertion that any such shape as I've described would be
> too slow to use?

No, that would work fine.  And I have indeed often wanted just a stackable
set of textboxes, which should be relatively easy with this.

> Broadly speaking, I think it's possible to cache the SVG data in a
> structure well-suited to efficient display.  I think that's what you mean
> by "What object/custom does is much saner: slurp the stuff into an
> efficient format (for the machine".

Curious aside:  A designed-for-the-purpose SVG renderer could be partially
evaluated down to C code.  Not easy to design the renderer so, though.

> Taking it a whole lap around the track, we have John's notion of
> aggregate objects.  Again, I'm afraid it's not clear to me; the
> discussion is so dense with jargon.  Is it aggregate SVG-based shapes
> that you find unwieldy?  Or are you concerned about pushing too much out
> to the XML layer, just trading off one form of complexity for another?

The latter, in my mind.  While the looks of the UML object can be made with
the above-mentioned SVG extension, the functionality of the attributes,
operations and interfaces are more complex than would be workable in XML.

The rework that would be nice at some point (probably after GTK 2.0
rewrites) is to make it easy to combine SVG shapes and C code.  Perhaps
that is what you were thinking of?  'Twould be tricky, IMHO.

Again, sorry for getting into flaming mode, I thought you were proposing
much more extensive changes.

-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    | Retainer of Sir Kegg
will defend to the death your right to say it."    |   of Westfield
    --Evelyn Beatrice Hall paraphrasing Voltaire   | Chaos Berserker of Khorne