Re: [Tuxpaint-devel] Some issues related to the text tool
An award-winning drawing program for children of all ages
Brought to you by:
wkendrick
|
From: Albert C. <aca...@gm...> - 2008-05-31 08:52:41
|
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. |