Re: UrShape: Definition by controversy, CVS ready

[John Palmieri <johnp martianrock com>]

Sorry, I've been busy lately in my job search.  My network is coming along
great.  The biggest problem is going to be the electrical.  We need to place an
outlet in the basement for the switch and firewall.  After that I can start
being productive in terms of coding.  Can anyone recommend the best ISP I can
use with Linux while I wait for DSL to be implemented in my area?

Well on to more important stuff (comments inline as always):

Andre Kloss wrote:

> Hi again.
>
> First let me put the most important issues and facts together:
> * You have CVS access at con-struct.sourceforge.net

Ok, there is no code there right now.  Perhaps we should get a snapshot of Dia
in there that we can work off of and create patches with.  Which is best,
directly from CVS or one of the tar balls?

>
> * The UrShapeBehaviour is still undefined.

I would think just "draw" and "resize" should be implemented right now.  They
both would take the calling UrShape and self as parameters.  Actually, only
containers should have a resize behavior.  All other children of containers
would be resized by the container itself.

I'm rethinking my first everything is inherited from UrShape.  How about
s/UrShape/UrTree/g; And a new class UrShape which has-a UrTree.  Actually
UrShape would just be a special case container.  UrShape will inherit from
element and the UrTree will cease to inherit from element in which case it will
need the x,y,height,width attributes.  UrShape will act as the middleware or
glue to dia while the UrTree can be free from any of the restraints of Dia's
architecture (except from the fact that we still need to use C).  This way if
Dia's internals change we simple make changes to UrShape while leaving the rest
of the code intact.

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

In the case of the resize behavior the event should cascade.  In this case the
UrShape could be thought as a container.  It traverses through each of its
children and manually resize them.  When it gets to another container it
triggers the containers resize behavior and the process starts again until all
containers have been resized and have manually resized everything else.  I don't
think you can actually call this pre-order but it is similar.  Shapes with
complex structures can utilize threads to accomplish the processing since each
container can be resized in parallel once it knows its parents size.

Draw is a different story since SVG uses a painters algorithm.  Pre-order would
be correct here.

As for mouse events a style similar to the cascade should be used.  UrShape
recives the event from Dia. It looks through all its children and finds the
bounding box that matches the mouse's x,y.  If the element is a container the
process starts all over until one of the other shapes are hit(UrSVG or
UrWidget).  If that shape does not have a handler for that particular behavior
the event propagates up the parent list until it finds a shape that does
implement the handler or reaches the root node.  In reality to save processing
power a container will check if the handler is implemented in its child and stop
if it is not (or execute its own handler).

Key events are handled by whatever component has focus.  UrWidgets and the
UrShape are the only components that can have focus.

One thing I need to know is how does Dia handle drawing?  Can I get a piece
canvas from Dia to do my drawing on or do I have to do everything on the main
Dia canvas?  Can GTK+ widgets be placed on this canvas or must we cheat and
place them on a layer above the canvas?

--J5