Re: UrShape Layout controversy

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

Hi, folks.

Let's pull the pieces together:

Lars writes:
> There's a thing you will have to consider at some point (though
> maybe not yet):  If you have an UrContainer A with an UrContainer
> B within it, how do you add further UrShapes to A? 
a) Every UrContainer needs to have some border, at least with snapping
b) Every UrContainer knows by his type if it can hold another UrShape,
and will resize automaticially when the UrShape is dragged over (and
if not dropped, restore the original size).

> You will also need a way to get UrShapes out of UrContainers.
That a UrShape snaps to a UrContainer doesn't mean it can't be dragged
out of it anymore.

John writes:
> Hehe.  Well lets see if I can clarify what I was thinking.
Let's see:

> Agreed, the Glade part was the drag and drop stuff which would be
> nice to have but turns Dia into a shape creation program instead
> of a diagramming tool. 
Not really. It just adds the option to embed UrShapes within other
UrShapes in order to create trees of shapes.

> I say that this is good to have in the future but as a separate
> developers mode (Perhaps even having the ability to edit scripts).
> Of course we could always add a drag 'n drop container that can be
> used for shapes that need this ability in design mode.
Since _I_ need this ability, I will certainly implement it.

> Oops, what I meant here is that they dictate the layout of a small subset of
> GTK+ widgets.  Yes they should be able to hold anything that is a UrShape.
Ok. Good we cleared that point.

> > I do not want to create shapes. I want to create trees of shapes.
> Understood.
Perfect.

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

> > > * Layout based on containers
> > What do you mean here? Layout is just the positioning of shapes.
> Layout is the positioning of shapes based on the size of the
> containers which is based on 2 things:
You mean the behaviour rather than layout.
> * Manual resizing
Every UrShape that is not within a UrContainer can be resized at
will. No prob here. If a UrShape is within a container, it may resize
the container and the parent UrShape. As you can see from the
UrContainer definition, the UrContainer stores row- and
column-positions. This means if an embedded UrShape is resized, it may
resize the whole array/table. The UrContainer needs to make enough
place for every UrShape it can contain.

> * Size of widget within the container (i.e. as the user types TextBoxs get
> bigger)
Unlimited.

> We have to make sure this is consistent, smooth and works in a
> visually pleasing manner. Should they grow, up, down, sideways?  
a) As long as we lack resizable Text, they should grow in whatever
direction is needed. Textboxes sould do line breaking (optional).
b) If we can scale embedded UrShapes, we do not need resizing of outer
shapes. That does not mean we may not use resizing anyway.

> Should restrictions be put on textbox growth?  Should we allow to
> restrict horizontally? vertically? Should we have a min and max
> size of widgets and then add scrollbars beyond that point?
Not. If the user wants to display something we should let him do that
without boundries.

> Layout is the big issue here.
Agreed.

> Personally I don't like how the current shapes with text expand
> (In all directions) but that is a judgment call I will not make on
> my own. If everyone wants the UrShapes to expand the same way
> then so be it.
I think the best possibility is to let them expand as much as needed,
with an option to wrap text at some fixed border or at some aspect 
ratio.

> > I prefer Chapin charts.
> Enlighten me to what a Chapin chart is.  I was referring to the
> textbox widget as being a simple one to use at first.
Oh, you mean no SVG test but rather something really simple. Ok, so be
it. Chapin Charts btw. are also known as Nassi-Shneiderman-Diagrams or
Structograms,


-- Tolerance rulez, everything else sux! -- Andre Kloss