UrShape: Some more ideas

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

Hi again.

On Mon, 16 Jul 2001, John Palmieri wrote:
> Can anyone recommend the best ISP I can use with
> Linux while I wait for DSL to be implemented in my area?
Where is your area? ;)

> Well on to more important stuff (comments inline as always):
> [CVS]
> 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?

> [UrShapeBehaviour]
> 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.
Wait a sec...This is already defined in the Object inherited-from
Element inherited-by UrShape.
But you made UrShapeBehaviour a member of the UrShape struct. Do we
really need this?

> 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. 
I don't like making things more complex than they are. UrShapes
already implement a tree, so they don't need to [have] a tree. I don't
think we should make too much use of C OO, since the added pointer
and typecasting mayhem makes our code unreadable.

> 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).
Well, C is no problem, if it doesn't come to OO ;)

> This way if Dia's internals change we simple make changes to
> UrShape while leaving the rest of the code intact.
That's a good point. However, I don't think the core will change that
much that it breaks Shape code.

> [Tree traversal]
Resize: Well, since this is implemented within the UrShape, it should
be no problem. It just forwards the call to all children. There is no
specified order needed.

> Draw is a different story since SVG uses a painters algorithm.  
> Pre-order would be correct here.
Yes. First the parents, then the children.

> As for mouse events a style similar to the cascade should be used.  
Agreed.

> UrShape recives the event from Dia.
How? By Callback? What actually _are_ events? I thought this would be
something like move, resize, select, etc.

The event propagation then depends on the event:
* Move does not need to be propagated, since all positions are
relative.
* Resize has to be propagated if a fixed ratio or any other constraint
is specified. Unresized UrShapes don't need to resize their children.
* Draw needs to be propagated, parents first.
* Select is propagated
  - if the shape that was selected before contains the selection in
    it's bounding-box (then it's parent is selected)
  - if no shape is selected, then the event is propagated to the
    "youngest" decessor still having the selection in its bounding
    box.
In this way, we have a cleanly defined behaviour and the user can
reach every UrShape in the tree.

> 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?
How do the UML comments do it?

> --J5
cu Andre
-- 
Tolerance rulez, everything else sux! -- Andre Kloss