Re: UrShape: Definition by controversy

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

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

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

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? *** */

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? ***/

/*  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? ***/

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

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

  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? ***/

};

/*UrSVG -- inherits from  UrShape*/
struct _UrSVG {
  UrShape deceased_rich_uncle;

  UrSVGType type;
};

/*UrWidget -- inherits from  UrShape*/
struct _UrWidget {
  UrShape deceased_rich_uncle;

  UrWidgetType type;
};