[prev in list] [next in list] [prev in thread] [next in thread]
List: koffice-devel
Subject: Re: Tools and plugins
From: kudling () kde ! org
Date: 2002-09-25 6:40:11
[Download RAW message or body]
> 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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic