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

[John Palmieri <johnp martianrock com>]

Hehe.  Well lets see if I can clarify what I was thinking.

Andre Kloss wrote:

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

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

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

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.

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

Understood.

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

Yes.

> > * 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:
* Manual resizing
* Size of widget within the container (i.e. as the user types TextBoxs get
bigger)

We have to make sure this is consistent, smooth and works in a visually pleasing
manner.  Should they grow, up, down, sideways?  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?

Layout is the big issue here.  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.

> > * A simple widget to test container layout
> 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.

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

If you feel confident then go for it.

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

Yep, though I wish C++ played nicer in the dynamic sense.  Too bad ObjectiveC
never really took off like C++.  I think the only reason GNOME and Gtk+ use C is
because it is so easy to bind to other languages.  Oh well.

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

--J5