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

[John Palmieri <johnp martianrock com>]

Andre Kloss wrote:

> Hi folks, especially John and Cyrille, since you two seem to give the
> most constructive feedback.
>
> As you may (or may not) know, time is of the essence for my purpose,
> so I'm seeking help _fast_. The UrShape is now somehow defined, but
> still far from implementation.
>
> What we need are the needed callbacks ready to implement. Then we can
> try and implement them, so we see where the hooks and angles are.
>
> NOTES: I have renamed the Container to UrContainer, since I found a
> Container in dia/app/gtkwrapbox.h and I want to disambiguate. I added
> a list of borders for the UrContainers, where the layout information
> can be stored. In this scope, relative[width|height] become obsolete.
>
> There are still some open Qs from the last proposal:
>
> 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?  I don't think interaction with
containers is necessary, at least for the first iteration of UrShape.
Containers are just there to hold a small subset of GTK+ widgets.  I would
think it were pretty annoying if I were dragging a shape across container
and it was suddenly sucked in.  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.

> What _do_ we have to implement?

We need to implement _first_:
* Rendering on the dia canvas
* Grab points for manually resizing
* Layout based on containers
* A simple widget to test container layout
* Load UrShape files
* Save UrShapes within Dia documents

>From there we can implement  more widgets, the use of arrays, callback and
scripting.

> In
> element.h, I find the following:
>
> void element_update_handles(Element *elem);
> /* What does this do? */
> void element_update_boundingbox(Element *elem);
> /* What does that do? */
> void element_init(Element *elem, int num_handles,
>                   int num_connections);
> void element_destroy(Element *elem);
> void element_copy(Element *from, Element *to);
> void element_move_handle(Element *elem, HandleId id,
>                          Point *to, HandleMoveReason reason);
> /* Here goes much functionality. How to implement standard
>    behaviour? (As described in Part III) */
> void element_move_handle_aspect(Element *elem, HandleId id,
>                                 Point *to, real aspect_ratio);
> /* Why this? Does this differ from move_handle? Do we need it? */
>
> void element_save(Element *elem, ObjectNode obj_node);
> void element_load(Element *elem, ObjectNode obj_node);
> /* This certainly belongs to the parser, right? It seems that this
>    relies on DOM to work. How to integrate SAX here? */
>
> /* Do we have to implement more stuff? If so, what stuff? How much
>    and what code can we C&P from custom shapes? */
>
> I'm glad you've read this far. If you know some answers, please post.
> I hope we can go into the implementation once these Qs are answered.
> cu Andre
>
> 8<-----------------------------UrShape.h--------------------->8
>
> /* urshape.h : defining the generic UrShape */
> #ifndef URSHAPE_H
> #define URSHAPE_H
>
> #include "element.h"
> /* What else has to be included? */
>
> typedef enum _UrContainerType UrContainerType;
> typedef struct _UrContainer UrContainer;
> typedef struct _UrShape UrShape;
>
> enum _UrContainerType {
>   SINGLE,
>   HORIZANTAL_ARRAY,
>   VERTICAL_ARRAY,
>   TABLE
> };
>
> struct _UrContainer {
>   Point relative_position;
>   UrContainerType type; /* This will define behaviour */
>   GList *rows;          /* The left border of rows */
>   GList *columns;       /* The upper border of columns */
> }
>
> 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.

>
>   /* UrShape container stuff */
>   UrContainer *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
>
> _______________________________________________
> Dia-list mailing list
> Dia-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/dia-list

--J5