On Mon, 17 Apr 2000, Gilles J. Seguin wrote:
> Alexander Larsson wrote:
> >
> > On Mon, 17 Apr 2000, Arjan J. Molenaar wrote:
> > > I'm quite charmed by the way constraints can solve placement problems,
> > > but since I never did anything using constraints (well, except
> > > programmatical constraints, which are quite inflexible) I'm not sure
> > > where this will end.
> > >
> > > DIA could also benefit from such a canvas, but I don't know when...
> >
> > In such a canvas i don't think constraint solving or even
> > connection-points should be handled. Just generic code for "objects" that
> > can be "drawn" and positioned. Maybe some generic trasformation too. We
> > need to steal some ideas from gnome-canvas, combine with Dia ideas and new
> > ideas and make a perfect canvas.
>
> Again, we see some conflicts because of termonilogy.
>
> In Dia, the grapples/handles uses to resize a widget are call
> connection points.
What I think Alex is getting at is that these sort of things would be
better left for the application to handle.
In the case of dia's connection point/handle idea, the GtkObject signal
system makes this particularly easy to handle. The derived canvas item
has a move_cp signal or something. When a handle is connected to the
CP, the object with the handle connects to the move_cp signal. When the
object with the CP moves, it emits the move_cp signal, which the allows
the connected objects to move themselves as well.
With such a canvas, all dia objects would probably be subclassed from some
special dia canvas item type, rather than the base canvas item.
I have put a small diagram of how some of the classes for a new canvas
might be arranged at:
http://www.daa.com.au/~james/images/new-canvas.png
I have gotten rid of the idea of layers, as they are really just groups
that are children of the root canvas item (I am not saying that dia should
get rid of its layers concept -- just that they don't need to be in the
base canvas implementation).
James.
