Re: UrShape definition Part IV: Full header (?)

[Andre Kloss <kloss rbg informatik tu-darmstadt de>]

Hi again. John, you raised some points I dislike, so here's what I
think:

> > How can UrShapes interact? If a UrShape is dragged over a (free)
> > UrContainer, it should snap into it until dragged out again. Any
> > UrContainer that has means of containing another UrShape should resize
> > to make place for one if one's dragged over. How does a UrShape know
> > what UrContainer it is over?
> 
> H'mm,  me thinks this is a bit complicated.  Are we trying to make this
> into a widget layout program like Glade? 
No. Don't mistake UrShapes as widgets. Think the bigger picture: A
UrShape is some SVG plus Text plus UrContainers. UrShapes can build an
arbitrary deep tree. The only widget we need (yet) is a textbox.

> I don't think interaction with containers is necessary, at least
> for the first iteration of UrShape.
Ok, first put it on the screen, then make it work. Agreed, for the
first iteration.

> Containers are just there to hold a small subset of GTK+ widgets. 
I disagree on this point. UrContainers are just there to hold whatever
we want them to hold - as long as it's a UrShape ;)

> I would think it were pretty annoying if I were dragging a shape
> across container and it was suddenly sucked in. 
But only if you drag it to the container and drop it within a
(adjustable) range of it. If you drag further, nothing happens (yet -
maybe wa may want some more visual feedback in the future). I don't
think that this would be too annoying. Maybe each diagram type could
have its own "embedding" range?

> This might be good for a separate shape creation mode to make it
> easy to create new shapes but for right now doing them by hand
> with the UrShape DTD would be the best thing.
I do not want to create shapes. I want to create trees of shapes.

> We need to implement _first_:
> * Rendering on the dia canvas
As seen in custom_object. This includes the SVG subset and text boxes.

> * Grab points for manually resizing
You mean the handles? If so, we'll just follow the implementation in
whatever uses elements.

> * Layout based on containers
What do you mean here? Layout is just the positioning of shapes.

> * A simple widget to test container layout
I prefer Chapin charts.

> * Load UrShape files
Yep. That's what I'll write the parser for.

  * Load UrShapes from within Dia docs
(You forgot this)
> * Save UrShapes within Dia documents
Here I'm undecided, since I'm wading not deep enough in the code to
know the interface to the core, but I believe we'll stick with DOM
here.

> From there we can implement  more widgets, the use of arrays, callback and
> scripting.
I come more and more to the conclusion that we should add a callback
hash in the first place. It will not disturb our design and I'm quite
convinced that this will be how we implement it later anyway.

[snip]
> > struct _UrShape {
> >   Element element;      /* Inheritance (C sometimes sucks ;) */
> 
> This is why I want to use GObject since it brings OO to C in a more
> complete manner well, more standardized (by GTK+) manner.  I guess we can
> wait until the rest of Dia moves to GObject and GTK 2.0 compliance.
Certainly. Let's just run with the wind, not ahead. ;)

> --J5
cu Andre
-- 
Tolerance rulez, everything else sux! -- Andre Kloss