Re: UrShape Layout controversy




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





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]