Re: UrShape: Definition by controversy, CVS ready

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

Hi again.

First let me put the most important issues and facts together:
* You have CVS access at con-struct.sourceforge.net
* The UrShapeBehaviour is still undefined.
* In what order do we traverse the tree? Remember we have two axes: Up
(Parent), Down (First Child), Left (Older brother), Right (Next
younger brother). I would think Pre-order, left to right should do
what we want most of all cases.

On Mon, 9 Jul 2001, John Palmieri wrote:

> I was just being morbidly funny.  Parent was taken so inherited or
> superclass would be best.
Ok, my vote for s/deceased_rich_uncle/inherited/g; What about multiple
inheritance? ;)

[Everything is a UrShape]: I juggled the thought around in my mind,
and I think it speaks against my (computer-science-trained) intuition.
A UrContianer IS a UrShape? Really really?

[Free-typed Hash]
> Ok, this sounds good.  I would think that the dynamic behavior
> would know what type the attribute is.  Do we want a type checking
> overhead? 
Why do we want a hash? For fast access? Do we really need fast access
to information we will only use in dynamically loaded functions? Since
all hard-coded stuff can go into a struct.

> I guess we could add a way for accessing type information but make
> it so you can access the data raw from the hash if speed is a
> concern.
Well, we could add some 
struct { enum { .. } type; union { .. } value } foo; Then we had
type-checking in its pure form.

> > typedef gint (*node_proc)(UrShape*); /*function that takes UrShape *
> >         as an argument should return 1 to continue and 0 to stop
> >         *** Is this for the end nodes? *** */

> No, it is for event propagation.  If one UrShape captures a
> mouse_down event you don't want it propagating to other shapes.  
> This way the generic function for_each_back can be set up to
> propagate events, once an event is captured the passed in node
> processing function tells ur_foreach_back to stop stepping through
> the tree.
I disagree on this point. We know all event-like function calls at
compile time. All calls will be propagated "from father to son". In
this way, every UrShape can decide for itself whether to block such a
call or not. There's no need for a generic "blocker" function, since
the forall (tree-running) functions will traverse the whole tree
anyway.

> >   char *id; /*should we use GTK+ strings?
> >               Every node can have a hash ID
> >               for use with scripting*/
> >   /*** Is this id unique? Or more like a class name? ***/
> Yes it should be unique but this is defined by the creator of the object
> <textbox id="UMLClassName"></textbox>
Do you mean unique like in "unique class of objects" or like in
"Highlander"? I would prefer the former.

> If it is not unique then that is the shape creators fault and
> should throw up an error. We need name spaces here to deal with
> shapes created with in dia from other shapes but again that is the
> scripting phase.
Ok, far away on our to-do-list.

> > /*  int row,column;  For all but SINGLE, it'll be nice to know in what
> >                      row/column the UrShape is embedded.
> >                      *J5* shouldn't this be queried
> >                      (parent->getRow(self)) instead of
> >                      holding it itself? */
> >   /*** Agreed. But where is it stored? ***/
> Stored in the container.  The container needs to know what row and
> column the widget is in to do layout so it has to store it
> somewhere (even if it has to count by doing a search of the list
> this is Ok because a function will do this very infrequently and
> store the results locally for processing).


> peer is the left side of the binary tree while child is the right.
That is somewhat misleading.
> Self I guess is redundant since the behaviors can't work without
> first passing in a pointer to the structure.  Ah lovely C OO
> again.
Yes, self is redundant, we can skip it. Just think "func(foo, ...);"
as foo->func(...); And if you really want it: #define foo->self foo ;)

> >   GList *children;
> >                      /*** Well, what about HBOX, VBOX, TABLE?
> >                         Ok, maybe we would go better to define some more
> >                         structure that would hold things like
> >                         (position/order)? ***/

> You just follow the peer pointers.  Well, lists work I just don't like
> having to deference them.
So far so good, if you insist 
on implementing Just Another List... Hey, that rhymes!

> With peer pointers (and I just realized we would have to have a
> pre_peer and post_peer for moving up and down a peer list) every
> node is the same. You can pass any node to a function and start
> traversing from there. With a list you would have to jump up to
> the parent, find out where in the list the node is located and
> then start processing from there.
That leads to the questions in what order do you want to traverse the
tree?

> >   GList *rows;          /* The left border of rows */
> >   GList *columns;       /* The upper border of columns */
> >   /*** This could go into some HBOX/etc. struct, too? ***/
>
> Yes, hmmm I wanted to avoid separate classes for each of the
> containers but I guess we would have to do it.  Let's implement
> one container for now and see how it goes.
Ok, with me. Let's start with the SINGLE container.

> My sourceforge id is quinticent.
Ok, I gave you developer access at con-struct.sourceforge.net

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