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.