UrShape definition Part III

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

Good morning, fellow developers and mailing list readers!

After a night of good sleep (which I have rather seldom these times) I
have some ideas of how to improve the header further. So I think, it's
time for Part III, so people can see any advancing. ;)

What I like to do in this part is defining the UrShape behaviour
informal (that is, in _my_ language - if you find it difficult to
understand, ask!) and provide a basic facility to store this behaviour
within a UrShape. So we have our behaviour definition first and at the
end, as last Part, the full header file.

The behaviour we have to provide is given by the defined function
pointers in object.h, so I just list this funcPointers and try to put
them into my words. An asterisk (*) says: Would someone please explain
to me, why and where this func is needed? 

I've sported another buzzword below, it's "container". I came to the
conclusion that we need some facility to store layout information for
potential children UrShapes. (That is, where is the child drawn?) To
store this information within the children is not enough IMHO, since
there may be no children at first, but we still need the layout
information for the time the first child comes. This will also make
max_children obsolete. So we will have some container struct that may
be handled as following:

typedef enum _ContainerType ContainerType;
typedef struct _Container Container;

enum _ContainerType {
  SINGLE,
  HORIZANTAL_ARRAY,
  VERTICAL_ARRAY,
  TABLE
};

struct _Container {
  Point relative_position;
  real relative_width;
  real relative_height;
  ContainerType type; /* This will define behaviour */
}

ObjectTypeOps:=======================================================
create;* is done like any other object, I guess
load;\ * Do they load and store the shape or the .dia files? 
save;/ Anyway, this will not vary much from the custom objects.
get_defaults; 
apply_defaults;

ObjectOps:===========================================================
destroy; This will destroy all child UrShapes, too.
draw;    Does the core know the child UrShapes? If yes, everything's
         fine as it is, but if no, this may have to draw the children,
         too.
distance_from; Business as usual, C&P from element.c
selectf; Here are more than one possible definitions:
         1. Business as usual
         2. A UrShape is selected. The next select selects the 1st
            child or the child which is at this position.
         It's mainly a thing of how layering is done. Beware that
         there may be UrShapes that are completely filled with
         subShapes and we might want to interact with'em nonetheless. 
copy;    deep_clone. This means we copy all the children, too.
move;    As in element, but go down the tree and move the children,
         too (By invoking the moveHandle function of the child:
         moveHandle(child->data,1st,(x|y),HANDLE_MOVE_CONNECTED, 0);)
         Another issue is that UrShapes should not only snap to grid
         but also _be_ a grid for other UrShapes, that are to be
         embedded (made children). UrShapes should snap to UrShape
         containers. An array or a table should resize if a new
         child is added.
move_handle; This will also do the resizing. So there's the first
         bigger issue: When a UrShape is embedded, may it be resized?
         And in which dimension? Should there always be 8 handles or
         just the handles that are needed to perform all possible
         operations? This will decide if UrShapes are Objects 
         or Elements. My proposal here is that embedded UrShapes are
         resized only through operation with the containers.
get_properties; A tree view of the properties? Would be neat...
apply_properties; business as usual.
get_object_menu; * Do we need this? If not { return NULL; }
describe_props; business as usual.
get_props; dito.
set_props; dito.
===================================================================

So far so good. Enjoy.

cu Andre
-- 
/* urshape.h : defining the generic UrShape */
#ifndef URSHAPE_H
#define URSHAPE_H

#include "element.h"
/* What else has to be included? */

typedef enum _ContainerType ContainerType;
typedef struct _Container Container;
typedef struct _UrShape UrShape;

enum _ContainerType {
  SINGLE,
  HORIZANTAL_ARRAY,
  VERTICAL_ARRAY,
  TABLE
};

struct _Container {
  Point relative_position;
  real relative_width;
  real relative_height;
  ContainerType type; /* This will define behaviour */
}

struct _UrShape {
  Element element;      /* Inheritance (C sometimes sucks ;) */

  /* UrShape container stuff */
  Container *embedding; /* NULL if free, "parent's" container else */
  int row,column; /* For all but SINGLE, it'll be nice to know in what
                     row/column the UrShape is embedded. */
  GList *childrenContainers; /* The containers I have */

  /* The miniDOM. Thanx to Cyrille, now it _is_ mini. */
  UrShape *parent_shape;
  GList *self; /* this->self->data == this */
  GList *children; /* (this->children->data->parent_shape == this ||
                       this->children == NULL) */
};

#endif