Re: [Tuxpaint-devel] Some issues related to the text tool

[Albert C. <aca...@gm...>]

On Tue, Jun 3, 2008 at 1:01 PM, Bill Kendrick <nb...@so...> wrote:
> On Tue, Jun 03, 2008 at 03:40:16AM -0400, Albert Cahalan wrote:

>> A fine point in time is when another tool gets used.
>> Magic tools should have a callback to tell them that
>> they should dump any saved state. This gets called as
>> soon as some other tool is used.
>
> Understand that the #1 reason people want an 'editable' text tool is
> because merely hitting Undo isn't sufficient.  Kids make mistakes, and
> want to go back and change or move their text way after the fact.
> (i.e., they finish making their drawing, then their teacher comes and
> tells them they made a typo or misspelling)

They can paint over it.

Kids do make mistakes. Facing the consequences
is a learning experience.

>> I could have used such a callback when I wrote the
>> bricks tools. The bricks tools keep track of brick
>> relationships so that they can join bricks together,
>> but this info must be forgotten when another tool
>> modifies the canvas. Currently the bricks tools get
>> rid of their state when the mouse button is released,
>> which is not ideal.
>
> In considering how a strokes-to-font tool could work (what I imagine
> as a 'stage 1' to Namrata's Big Idea of a writing training tool),
> I realize we'd need some means of telling the tool "I'm done with a letter",
> after multiple strokes.  (We're not doing "one click-and-drag for an entire
> letter" like PalmOS Graffiti...)

I hope that isn't going in to Tux Paint. It doesn't have
even the slightest reason to be part of a paint program.
As a stand-alone program, it is somewhat sensible.
(subject to the problem of learning without paper)

> It occured to me we could put a little 'checkboxs' button next to their
> strokes, or at the bottom of the canvas, or somewhere.  The Magic Tools
> can easily do this (see the crosshairs that appear over the entire canvas
> when you use the Move magic tool).  However, for this tool to not splat
> checkmarks on the drawing when the user happens to switch tools, or hit
> Save, or ..., I think we _do_ need a "this tool is finished" clean-up call.

That too.

"this tool is finished" is distinct from "some other tool has
mucked with the canvas".

The "some other tool has mucked with the canvas" case might
best be attached to the history mechanism. The history gets a
pair of pointers for each undo level. One pointer is tool-private
data. The other pointer is a clean-up function.