Re: UrShape Layout controversy

[John Palmieri <johnp martianrock com>]

Andre Kloss wrote:

> Hi, folks.
>
> Let's pull the pieces together:
>
> Lars writes:
>
> > 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.

Now I see what Chapin Charts are.  Very nice.  A specialized UrDNDContainer (Drag
n Drop) can be used here which will allow dragging in and out.  As for figuring
out which shape to drag out modifier keys for selection can be used. For example
there is a container (shape) within another container which is itself within a
container.  I want to move the middle container out, so I select it by clicking on
its border.  Now, its border is big enough for me to select it but every time I
try to drag it I miss the border and select the inner container.  To avoid this I
should be able to hit a modifier key (alt for example) and click anywhere inside
the rectangular selection without deselecting my original selection.  Now we can
drag.

>

> 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 see now with the Chapin Charts.

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

Behaviors I see as being more advanced ways of specialized layout (and user
interaction).  Layout I see as a default layout mecanism (with a few options) so
that a developer can create simple UrShapes quickly.  Behaviors I see as being
able to override the original layout for shapes that need more complex handling.

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

Should be limited by the shape designer.

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

But what is the default?

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

Ok, what I am getting at here is that certain shape work better with boundaries.
For example UML shapes would do best to grow only in the positive x,y direction
when text is added. Some shapes might want to keep an aspect ratio.

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

Chapin Charts can be used as a test bed but I was thinking of SVG tests on the
layout using a simple textbox widget to facilitate resizing of the container.  How
about this - test with simple shapes (I sent some test shapes over with the dtd)
then move to developing both Chapin Charts and the new UML diagrams.  They both
have different uses and would make a good point, counter point conversation on
what features to implement so that UrShapes are flexible.

> -- Tolerance rulez, everything else sux! -- Andre Kloss
>
> _______________________________________________
> Dia-list mailing list
> Dia-list gnome org
> http://mail.gnome.org/mailman/listinfo/dia-list

--J5