tuxpaint-devel

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

[vudem a. <aru...@gm...>]

About being able to select the text long long time after the text has
been entered.  We could save the data in the list where information about the
text is present. Now when open is used and the corresponding drawing
along with the list informations gets loaded. Thus it can be edited.
but with support for system dialogs coming up and renaming of files
being a possibility this will not be good enough. Is there someway in
which we ca handle this problem. The file naming convention could be
kept simple like all the files related to xxx.png could be
xxx-lyyy.png where yyy would be the layer number. Can we work around
this so that the same filename cannot be used in a different
directory. All the other files could b e saved in the current tuxpaint
saving directory except the whole drawing.

I am also thinking of ways in which we change the background image
when text is selected. The problem that we face here is as follows:
Suppose the text is entered, and smudge is applied in the area of the
text. Do we go back to the state where the text as well as the
background image are desmudged and the text displayed or do we keep
the background smudged, while only the text is displayed, desmudged.
Currently I am thinking of implementing it by applying it(perhaps all
the magic tools) separately for the text layer and the background
image, so that that when the text is selected, the magic applied
below it can remain as they were before. Do we apply magic tools to
each of the layers, text and drawing separately?

Another issue I was thinking was about drawing above the text. How do
we handle that situation. Suppose the text is partially covered and a
brush is used to draw an top of the text. We will now have to even
support and keep information about multiple layers of drawing on top
of the text layers. I do not know if this will involve a large scale
re-engineering of the tuxpaint code. What do you think about it?

Regards,
Arunodai

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

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

On Sat, May 31, 2008 at 2:17 AM, vudem arun <aru...@gm...> wrote:

> About being able to select the text long long time after the text has
> been entered.  We could save the data in the list where information about the
> text is present. Now when open is used and the corresponding drawing
> along with the list informations gets loaded. Thus it can be edited.
> but with support for system dialogs coming up and renaming of files
> being a possibility this will not be good enough. Is there someway in
> which we ca handle this problem.

There is no "undo" support for freshly loaded files.
The history is not saved with the image.

This is proper behavior.

> The file naming convention could be
> kept simple like all the files related to xxx.png could be
> xxx-lyyy.png where yyy would be the layer number. Can we work around
> this so that the same filename cannot be used in a different
> directory. All the other files could b e saved in the current tuxpaint
> saving directory except the whole drawing.

Don't go there. (big mess)

> I am also thinking of ways in which we change the background image
> when text is selected. The problem that we face here is as follows:
> Suppose the text is entered, and smudge is applied in the area of the
> text.

The text is now uneditable.

> Do we go back to the state where the text as well as the
> background image are desmudged and the text displayed or do we keep
> the background smudged, while only the text is displayed, desmudged.
> Currently I am thinking of implementing it by applying it(perhaps all
> the magic tools) separately for the text layer and the background
> image, so that that when the text is selected, the magic applied
> below it can remain as they were before. Do we apply magic tools to
> each of the layers, text and drawing separately?

No layers! It's too slow, it eats too much memory,
it makes the UI complicated, and it makes the code
harder to understand.

> Another issue I was thinking was about drawing above the text. How do
> we handle that situation. Suppose the text is partially covered and a
> brush is used to draw an top of the text.

That text is now just part of the image. Any notion of
it being text is long gone.

> We will now have to even
> support and keep information about multiple layers of drawing on top
> of the text layers. I do not know if this will involve a large scale
> re-engineering of the tuxpaint code. What do you think about it?

"large scale" is an understatement. This is massive.

BTW, I'd like to point out my hardware specs.
I have an OLPC XO-1. Many kids have these.

The XO has 256 MB of RAM, but most of that is
consumed by a bloated desktop. About 80 MB may
be available. The screen resolution is 1200x900,
which is quite a lot for a low-end system. Remember
that Tux Paint's memory usage greatly depends on
the screen size.

The XO's CPU has performance similar to a K6,
Pentium MMX, or low-speed Pentium II. Think of
a MHz value of around 200.

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

[Mark K. K. <mkk...@gm...>]

There are quite a few threads, both private and public, regarding the
text tool enhancement.  If it's okay with everyone, I'd like to
consolidate them into this single public thread to reduce redundancy.

To give you some background information, Arunodai is enhancing the Tux
Paint text tool for Google Summer of Code.  I am assigned as his mentor.
The requirement is that the text tool, once used to enter text into the
drawing area, can be edited at a later time.  The details are up for
discussion, which will benefit from this public discussion.

First, let me respond to the public thread on this mailing list, to
which Albert responded last as follows:

On Sat, May 31, 2008 at 04:52:42AM -0400, Albert Cahalan wrote:
> On Sat, May 31, 2008 at 2:17 AM, vudem arun wrote:
> 
> > About being able to select the text long long time after the text has
> > been entered.  We could save the data in the list where information about the
> > text is present. Now when open is used and the corresponding drawing
> > along with the list informations gets loaded. Thus it can be edited.
> > but with support for system dialogs coming up and renaming of files
> > being a possibility this will not be good enough. Is there someway in
> > which we ca handle this problem.
> 
> There is no "undo" support for freshly loaded files.
> The history is not saved with the image.

Albert's statement is technically correct, but I think he may have
misunderstood Arunodai's email.  Arunodai is specifically referring to
the mechanism of storing the text data, so the text data can be edited
later, not for undo operations.

> > The file naming convention could be
> > kept simple like all the files related to xxx.png could be
> > xxx-lyyy.png where yyy would be the layer number. Can we work around
> > this so that the same filename cannot be used in a different
> > directory. All the other files could b e saved in the current tuxpaint
> > saving directory except the whole drawing.
> 
> Don't go there. (big mess)

I agree creating several files for each drawing will be messy, but I
think the alternatives aren't much better.  The text data, if we want
the text to be editable across saving, will need to be saved.
Arunodai's proposal is to create one file per layer, where multiple
layers are required to store all the texts at different layers.  The
alternatives are:

  1. Choose a file format that can support layers so that only a single
     file is created.  MNG, XCF, etc.

  2. Save all non-text data into a single file in a proprietary format,
     so only two files are created.

  3. Don't do layers.  When the image is saved, it's saved in a single
     layer, with no further editing of text upon re-opening of the file.

  4. Save all extra data into PNG's meta-data area.

I would like #3, but Bill wants the text editable a long time after it
is entered.  Barring #3, other options will take long time to implement
correctly.  I only see multi-file format as the only other option.
Please suggest other options if there are other viable options.

I would like to see either a multi-file option or not doing layers at
all, at least for the initial implementation.  Perhaps #1 is the best
option in the long-term, but it's not practical for the GSoC timeframe.

> > I am also thinking of ways in which we change the background image
> > when text is selected. The problem that we face here is as follows:
> > Suppose the text is entered, and smudge is applied in the area of the
> > text.
> 
> The text is now uneditable.

Again, Bill wants the text editable a long time after it is entered.  I
think Albert's idea gives a cleaner solution, though, at least for the
first phase of the implementation.

> No layers! It's too slow, it eats too much memory,
> it makes the UI complicated, and it makes the code
> harder to understand.
...
> > Another issue I was thinking was about drawing above the text. How do
> > we handle that situation. Suppose the text is partially covered and a
> > brush is used to draw an top of the text.
> 
> That text is now just part of the image. Any notion of
> it being text is long gone.
...
> "large scale" is an understatement. This is massive.

All these are valid concerns.  Perhaps the thing to do here, given the
complications, is to allow text to be edited until a specific point
(e.g., until the text tool is de-selected) for the initial
implementation.  That way we can defer the file storage and magic-tool
interaction issues for another time.  For the initial impelmentation, we
can work out the interface and data structures.

My biggest concern, as the mentor for this project, is that I think the
file storage and magic-tool interaction issues are difficult problems
that we won't have time to work out thoroughly during the GSoC period.
Bill/Arunodai - would you guys be okay with this for now?  The other
features can be implemented as time allows, whether it be during GSoC or
following it.

There are several more issues I'd like to discuss that were raised in
private emails, but if Bill/Arunodai is okay with the above proposal I
think the remaining discussions can be deferred to a later time, with
the remaining GSoC time concentrated on the initial implementation.

-Mark

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

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

On Mon, Jun 2, 2008 at 4:12 PM, Mark K. Kim <mkk...@gm...> wrote:
> On Sat, May 31, 2008 at 04:52:42AM -0400, Albert Cahalan wrote:
>> On Sat, May 31, 2008 at 2:17 AM, vudem arun wrote:

>>> About being able to select the text long long time after the
>>> text has been entered.  We could save the data in the list
>>> where information about the text is present. Now when open
>>> is used and the corresponding drawing along with the list
>>> informations gets loaded. Thus it can be edited. but with
>>> support for system dialogs coming up and renaming of files
>>> being a possibility this will not be good enough. Is there
>>> someway in which we ca handle this problem.
>>
>> There is no "undo" support for freshly loaded files.
>> The history is not saved with the image.
>
> Albert's statement is technically correct, but I think he
> may have misunderstood Arunodai's email.  Arunodai is specifically
> referring to the mechanism of storing the text data,
> so the text data can be edited later, not for undo operations.

I understood. I consider the problem to be one and the same.
A saved+loaded file does not have all the history with it.

>>> The file naming convention could be kept simple like all
>>> the files related to xxx.png could be xxx-lyyy.png where
>>> yyy would be the layer number. Can we work around this so
>>> that the same filename cannot be used in a different directory.
>>> All the other files could b e saved in the current tuxpaint
>>> saving directory except the whole drawing.
>>
>> Don't go there. (big mess)
>
> I agree creating several files for each drawing will be messy, but I
> think the alternatives aren't much better.  The text data, if we want
> the text to be editable across saving, will need to be saved.

This "editable across saving" idea is extremely bad.

> Arunodai's proposal is to create one file per layer, where multiple
> layers are required to store all the texts at different layers.  The
> alternatives are:
>
>  1. Choose a file format that can support layers so that only a single
>     file is created.  MNG, XCF, etc.
>
>  2. Save all non-text data into a single file in a proprietary format,
>     so only two files are created.
>
>  3. Don't do layers.  When the image is saved, it's saved in a single
>     layer, with no further editing of text upon re-opening of the file.
>
>  4. Save all extra data into PNG's meta-data area.
>
> I would like #3, but Bill wants the text editable a long time after it
> is entered.  Barring #3, other options will take long time to implement
> correctly.  I only see multi-file format as the only other option.
> Please suggest other options if there are other viable options.

"don't" is best by far, followed by custom PNG tags, followed
by "tell people to use Kid Pix instead of Tux Paint".

> All these are valid concerns.  Perhaps the thing to do here, given the
> complications, is to allow text to be edited until a specific point
> (e.g., until the text tool is de-selected) for the initial
> implementation.

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.

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.

> That way we can defer the file storage and magic-tool
> interaction issues for another time.

Right. Let's plan to implement that on April 1, 2099.

> My biggest concern, as the mentor for this project, is that I think the
> file storage and magic-tool interaction issues are difficult problems
> that we won't have time to work out thoroughly during the GSoC period.
> Bill/Arunodai - would you guys be okay with this for now?  The other
> features can be implemented as time allows, whether it be during GSoC or
> following it.

Google says "Changes to milestones and your original project plan
are expected as part of the program." I don't think that excludes
picking something else to do.

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

[Pere P. i C. <pe...@fo...>]

Hi!

El ds 31 de 05 de 2008 a les 11:47 +0530, en/na vudem arun va escriure:

> I am also thinking of ways in which we change the background image
> when text is selected. The problem that we face here is as follows:
> Suppose the text is entered, and smudge is applied in the area of the
> text.

What about editing in "correction mode"?
Say draw just the changed letter(s) in a contrasted background.
No layers needed, no need to go backwards to know if some tool has
covered any part of the text, just keep the information of it and draw
the changed portion.


My two cents.
Pere

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

[Bill K. <nb...@so...>]

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)


> 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...)

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.


-- 
-bill!
bi...@ne...
http://www.newbreedsoftware.com/

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.

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

[Bill K. <nb...@so...>]

On Sat, May 31, 2008 at 11:47:47AM +0530, vudem arun wrote:
> I am also thinking of ways in which we change the background image
> when text is selected. The problem that we face here is as follows:
> Suppose the text is entered, and smudge is applied in the area of the
> text.

I think that text entered using this new tool (where text can be edited
later, moved around on the fly, etc.) should NOT be affected by Magic tools,
or painted over.  (Well, ok, if the Move tool or Mirror/Flip tools are used,
the X/Y coordinates of the text would change, but that's it!)

My thought is that we could call this the "Label" tool.
The text acts like it's on a separate layer, similar to the
coloring-book-style starter images.  (Except those literally get applied
to the final drawing canvas after every other draw event.  The Label text
would NEVER get applied to the drawing canvas, except during Save -- either
as an arbitary "ok, you can never edit that text again", which I don't love,
but would be ok with for the time being, or as a kind of 'export'...
i.e., you'd end up with three files:  canvas, text data, canvas with text
blitted on it (suitable for use in other applications, web, email, etc.))

-bill!

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

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

On Tue, Jun 3, 2008 at 1:06 PM, Bill Kendrick <nb...@so...> wrote:

> I think that text entered using this new tool (where text can be edited
> later, moved around on the fly, etc.) should NOT be affected by Magic tools,
> or painted over.  (Well, ok, if the Move tool or Mirror/Flip tools are used,
> the X/Y coordinates of the text would change, but that's it!)

Finally we have a layer-like idea that is at least theoretically
usable by kids and, more importantly, possible to implement.
I'm fairly sure that is still has unusable performance on many
machines, maybe including the OLPC XO. Crazy optimization
(use of MMX and 3DNow! assembly) may save the day.

For usability, I think you need to have fixed lines for the text.
Consider the problem of selecting a small letter with a big
letter on top of it.

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

[Mark K. K. <mkk...@gm...>]

On Tue, Jun 03, 2008 at 02:30:37PM -0400, Albert Cahalan wrote:
> On Tue, Jun 3, 2008 at 1:06 PM, Bill Kendrick <*************> wrote:
> 
> > I think that text entered using this new tool (where text can be edited
> > later, moved around on the fly, etc.) should NOT be affected by Magic tools,
> > or painted over.  (Well, ok, if the Move tool or Mirror/Flip tools are used,
> > the X/Y coordinates of the text would change, but that's it!)
> 
> Finally we have a layer-like idea that is at least theoretically
> usable by kids and, more importantly, possible to implement.

It sounds reasonable to me, also.  Unless others have concerns,
perhaps we can discuss the implementation details (below.)

To summarize, this is going to be a new tool, separate from the text
tool.  I believe bill referred to this tool as a "label tool" so that's
the term I'll be using below.

> I'm fairly sure that is still has unusable performance on many
> machines, maybe including the OLPC XO. Crazy optimization
> (use of MMX and 3DNow! assembly) may save the day.

If there are performance concerns, at least for the initial
implementation, we can just "turn it off" at compliation time.  For most
desktops I doubt it'll be a problem with some careful design.  Handhelds
may be an issue but we won't know how much impact it will have until we
try it out.

> For usability, I think you need to have fixed lines for the text.
> Consider the problem of selecting a small letter with a big
> letter on top of it.

In a private email, Bill had an idea of "repelling labels."  At least
for the initial implementation, I think preventing labels from being
written into the same box-area of other labels will be good enough.
Moving labels can also prevent itself from overlapping with other
existing labels.  With this mechanism, we don't have to worry about
multiple layers, selecting the correct label when attempting to edit it
when multiple labels overlap, figuring out which label should be on top
of which other label, etc., but it still allows free-placement of
labels (no snapping to predetermined lines.)



HOW THE DATA SHOULD BE SAVED
============================

There are several options here.  For simplicity, I think it's best to
have two files:

  1a. One PNG file without labels.
  1b. Label data embedded into the PNG file as comments.  The data
      includes the actual string, the coordinate of the string, the font
      name of the string, the font size, and the font color.

... with all label data redrawn at open-time.

There are some consequences of saving data this way.  One consequence is
that the image file, when opened with another image application, won't
show the labels.  We would have to remedy this by having some sort of
"export" option.  Another consequence is that the image won't always
look exactly right when opened by Tux Paint on a different computer
because the other computer may not have the right fonts, and depending
on the display size the image and the fonts will need scaling which may
displace the label location.

We could store the image *with* the labels to partially take care of the
latter issue, but that does not entirely solve the issue.  For example,
storing the labels with the image allows the image to be viewable from
another computer as the image was originally drawn, but it does not
allow the label to be edited with the same font, and cause the label to
get "mangled" as soon as it is edited.

I think we simply cannot expect everything to work correctly when the
image is opened on a different computer.  Given this limitation, I think
the above option (1a + 1b) is the simplest storage mechanism.



Thoughts?

-Mark