Re: UrShape: Definition by controversy

[John Palmieri <johnp martianrock com>]

Andre Kloss wrote:

> On Mon, 9 Jul 2001, John Palmieri wrote:
>
> > Ok, well here is my take on the UrShape.
> Cool. Let's see what we have here.
>
> > I rearanged the structures to be a bit more object oriented.  I
> > havent put in the behaviors yet.  This is just a skeleton.
> Ok so far. But I don't like the "deceased_rich_uncle" name. Rather
> stick with "parent" or "father" (or "mother" if you merely like
> it). ;) Or maybe "inherited"?
>

I was just being morbidly funny.  Parent was taken so inherited or superclass
would be best.

>
> > The gist of it is that everything is a UrShape with global ur
> > functions to manipulate the tree.  UrContainers inherit from
> > UrShape and are the only structures allowed to have children (this
> > is only partialy true since SVG defines its own parent child
> > relationships.)
> Ok. This evolves from my basic draft, in which I proposed UrContainers
> to hold only the layout information and behaviour stuff. But your
> proposal is ok with me.
>
> > UrContainer can hold UrShapes hence they can hold anything inherited from
> > UrShapes. We could define classes for each type of container but the bulk
> > of this will be handled by the dynamicly binded behavors and some sort of
> > attribute hash that hasn't been worked out yet.
> Either a hash or a struct (and a hash for seldom-used- /
> dynamically-binded behaviour or attribute).

>
> > Can we create a hash that can hold both text and numerical data so
> > that we don't have to convert each time we want access to an
> > attribute?  Hard coding these means classes for each type of
> > container, SVG shape and widget.
> Sure we can. We just need to know what of the two we have when we take
> something out of the hash, then it's just a simple typecast.

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

>
> In order to put our heads together, let's see what I can do to your
> code. I have commented my changes and questions below:
>
> Ok, here we go...
>
> 8<-------------------------------------------------------->8
>
> /* urshape.h : defining the generic UrShape */
> #ifndef URSHAPE_H
> #define URSHAPE_H
>
> #include "element.h"
> /* What else has to be included? */
> /*prototypes for UrShape*/
> UrShape *ur_document; /*root node of urshape*/
> UrShape *ur_current_node;
>
> /* this is just some functional programming to make processing a
> document easyer. Similar to the map function in scheme ur_foreach
> takes a tree of UrShapes, interates through every node and runs a user
> defined function on each node */
>
> /*hey if we are using OO why not functional(generic) programming
> too? hehe *** Sure! ***  */
>
> 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.


>
> void ur_foreach( UrShape *document,node_proc func );
> void ur_foreach_back( UrShape *document,node_proc func );
> /*same as foreach but iterates backwards to propigate events*/
>
> typedef enum _UrShapeType UrShapeType;
> typedef enum _UrContainerType UrContainerType;
> typedef enum _UrSVGType UrSVGType;
> typedef enum _UrWidgetType UrWidgetType;
> typedef struct _UrContainerBehaviour UrContainerBehaviour;
> typedef struct _UrContainer UrContainer;
> typedef struct _UrShapeBehaviour UrShapeBehaviour;
> typedef struct _UrShape UrShape;
>
> enum _UrShapeType {
>   CONTAINER,
>   SVG,
>   WIDGET,
>   CONNECTOR
> }
>
> enum _UrContainerType {
>   SINGLE,
>   HBOX, /* That's why we may want to have Lists... */
>   VBOX,
>   TABLE
> };
>
> /*more to come but for now this is fine*/
> enum _UrSVGType UrSVGType {
>   LINE,
>   BOX
> };
>
> enum _UrWidgetType{
>   TEXTBOX
> }; /* For now... I have no idea what else */
>
> /*UrShape -- inherits from element*/
> struct _UrShape {
>
>   Element deceased_rich_uncle; /*yay, inheritence*/
>   /*** Here we inherit also a struct to some layout
>        and behaviour defining functions ***/
>
>   UrShapeType type;
>   UrShapeBehavior *behaviour; /*** This is undef by now ***/
>
> /*  gint x; relative to container*/
> /*  gint y; height and width already defined by element*/
>   /*** Element inherits a bounding box from Object ***/
>
>   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>

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.

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

>
>   UrShape *parent;
>   UrShape *peer; /*** What for? ***/
>   UrShape *self; /*only containers can have children*/
>   /*** Same goes here: What for? ***/
> };

peer is the left side of the binary tree while child is the right. 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.

>
>
> /*UrContainer -- inherits from  UrShape*/
> struct _UrContainer {
>
>   UrShape deceased_rich_uncle;
>
>   UrContainerType type;
>   /*Now you may be asking yourself why no behavior?
>     Because, it is inherited as a pointer from UrShape.
>     A simple cast (UrContainerBehavior*)(deceased_rich_uncle->behavior)
>     will do the trick.  Funny C OO */
>
>   gint canDnD : 1;
>
> /*  UrShape *child;  I don't think lists are in order here. Should
>                      Lists be used instead of peer pointers?*/
>   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.  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.

>
>   Rectangle *bounding_box;
>   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.

>
>
> };
>
> /*UrSVG -- inherits from  UrShape*/
> struct _UrSVG {
>   UrShape deceased_rich_uncle;
>
>   UrSVGType type;
> };
>
> /*UrWidget -- inherits from  UrShape*/
> struct _UrWidget {
>   UrShape deceased_rich_uncle;
>
>   UrWidgetType type;
> };
>
> _______________________________________________
> Dia-list mailing list
> Dia-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/dia-list

My sourceforge id is quinticent.

-J5