> For example, I think that a tool to create a shape should be given access to 
> mouse events from the canvas, and somewhere to draw its thing. This is 

Well, we introduced mouseButtonPressed() mouseDragged() by intention: to
avoid that all tools reimplement much of thos lowlevel code over and
over again. What is missing there?

> the level of abstraction comes in. The tool would stick points in a buffer of 
> sorts, and, while that tool is still being used (dragging a circle across) 
> those points would be drawn on the canvas using the blue preview painter. 

What kind of points?

> Once the tool receives the correct mouse/keyboard events, it should say so, 
> and the buffer would be used to do the command creation for undo proccesses, 

You mean, what accept() does currently?

> A modifying tool should also have its own class. It would be given 
> mouse/keyboard events, and a copy of (not a pointer to..) the object(s) that 

Yes, hiding the implementation detail document()->selection()->objects()
doesn't hurt.

> At no time should the tool have to deal with anything underlying. Things that 
> are common to the tool classes should be done automatically by the base 
> class.

Agreed.

Bye
Lenny
_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel