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
_______________________________________________
Dia-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/dia-list
