Re: Shapes layout proposal

["James K. Lowden" <jklowden speakeasy org>]

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 probably only understand half of what you said, and since I respect your
opinion I'd like to find out which half that is ;-).  Besides, it's not my style
to show up and say "Here, let me show you how you should redesign your project."
Running code might be the better half of rough consensus.

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

I think you're going to say, no, what I'm describing is an enhanced version of
the UML class shape, which is implemented in C and would still be acceptably fast
if enhanced in this way.

Taking it one step further, a naive aspiring shape designer might like to think
it would be nice to be able to design a shape with the features I've described
using SVG.  Is it your assertion that the -- I don't know the proper technical
Dia term here -- the SVG interpretation layer would be too slow?  If your answer
is still no, we're of one mind.  If not, I'd like to show you it'll be OK on your
stone age Pentium, and I'd like to discuss how to provide you with acceptable
evidence.  AIUI, even this idea implies changes to the DTD, and I'm hoping John
will be willing to do that the Right Way, not least because I've never written a
DTD.

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

I would also like my shape to display different "layers" i.e., not all the text
all the time, depending on diagram-wide status fields.  But that's another
discussion.

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?

I still think I might be useful to this project, especially with guys like Lennon
and John to help shape the XML layer (no pun intended), but I don't want to be
working at cross-purposes.  Please help me understand what's what.  If there's
particular source code you think I should look at to understand what you're
talking about, say so.  I can read as well as write.  :-)

Regards,

--jkl