tuxpaint-devel — General discussion list for Tux Paint developers

[Tuxpaint-devel] An experimental tablet for TuxPaint

[Shih-Chin Y. <sya...@gm...>]

Dear all:
I found Tuxpaint to be a very good software for kids, but it might be a bit
difficult for kids to use mouse to draw on TuxPaint,

I have been working on a technology to offer an economic tablet for kids.
For the prototype, you could see the video demo at

http://www.imareader.com/coopaint.html

The tablet indeed has several distinct features from a Wacom tablet, such as
. Fully transparent;
. No sensor board ;
. Large area;
. Low cost.

I plan to make a product using the technology, but think I had better to do
some market research before doing. Do you think if parents would buy a
$39.99 tablet for kids to explore their creativity using TuxPaint?

I know this is a E-mail list for developers, not for market research. But
since most of you are experts in TuxPaint, so I hope that you don't mind I
ask such a question here.

Best regards,
Shih-Chin

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] Execution terminating

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

On Sun, Jun 1, 2008 at 8:49 AM, foo-script <foo...@o2...> wrote:

> How to let TuxPaint know, that something went wrong,
> eg. memory couldn't be allocated?

You don't.

You should detect errors if you can handle them.
If there is nothing useful to do when an error happens,
then there is no reason to check for it.

Memory allocation has an additional problem.
Most OSes do not return NULL, because they
assume that memory will become available.
The memory is not fully allocated until it is
written to. This allows the OS to give out more
memory than it has available. OSes do this
because most allocations are never fully used.

> I suppose that using perror, just like usually
> man does, is not allowed.

It's discouraged. Ignoring the error is often better.
If ignoring the error would cause a crash or worse,
then go ahead and use perror.

You can print to stderr. This should not happen
under normal conditions. Regular users are unlikely
to see the messages, and the printing will make
Tux Paint run slower.

[Tuxpaint-devel] Execution terminating

[foo-script <foo...@o2...>]

How to let TuxPaint know, that something went wrong, eg. memory couldn't be allocated? I suppose that using perror, just like usually man does, is not allowed. There's TOOLNAME_shutdown function but returns void, so how to note that an error occured? Is printing to stderr allowed?

Best,
Adam

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

[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] Idea: Tabs for magic tools

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

On Fri, May 30, 2008 at 06:15:27PM +0200, foo-script wrote:
> 
>  Andrew Corcoran writes new image filters (magic tools) whose affect whole screen just like some of currently tools do (flip, rotate etc). Wouldn't it be good idea to divide the filters into two sections: affecting whole screen and brush-like? Mention that after this SoC TuxPaint will have much more magic tools :]]
> 

>From a UI standpoint, I'm not sure whether it makes sense to divide them up
for that reason.

I'd like to see, as I've mentioned, the API and UI expanded such that
the 'drawing' Magic tools can _also_ provide a 'full-screen' action
(e.g., blur, negative, tint, etc.).  It won't make sense for some tools.
And some tools are already full-screen, and drawing makes no sense
(flip and mirror, although I _could_ see how they could be turned to
drawing tools, too :^D )

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

[Tuxpaint-devel] Idea: Tabs for magic tools

[foo-script <foo...@o2...>]

 Andrew Corcoran writes new image filters (magic tools) whose affect whole screen just like some of currently tools do (flip, rotate etc). Wouldn't it be good idea to divide the filters into two sections: affecting whole screen and brush-like? Mention that after this SoC TuxPaint will have much more magic tools :]]

 Regards,
 Adam

Re: [Tuxpaint-devel] Attempting to ressurect "uppercase only" code

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

On Thu, May 29, 2008 at 12:13 PM, Bill Kendrick <nb...@so...> wrote:
>
> So we're cleaning up a few things, and I realized that, for Pango-based
> builds at least, _most_ text in Tux Paint (tux tips and pop-up dialogs)
> were not honoring the "uppercase only" option.  ("--uppercase")

Given that most builds use Pango, I think you've just
proven that the feature isn't being used. Ditch it.
Unused code has maintenance and performance costs.

[Tuxpaint-devel] Attempting to ressurect "uppercase only" code

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

So we're cleaning up a few things, and I realized that, for Pango-based
builds at least, _most_ text in Tux Paint (tux tips and pop-up dialogs)
were not honoring the "uppercase only" option.  ("--uppercase")

I've dealt with that, but it's not working so well for non-English locales.
Anyone feel like lending a hand? :)

Thanks,

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

Re: [Tuxpaint-devel] savedir option bug

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

On Thu, May 29, 2008 at 07:56:35AM -0400, Francis Giraldeau wrote:
> Hi,
> 
> There is a bug with the savedir option, when specified in the
> configuration file. Environment variables are not replaced by their
> values. See :
> 
> https://bugs.launchpad.net/ubuntu/+source/tuxpaint/+bug/195868
> 
> I did a patch to fix this on Linux, but the function used is not
> available for other plateforms. Does someone know how to do this on
> Windows and MacOS?

Yes, I'd like to know, as well. :)


> At least, I think that the patch for Linux should be merged to fix the
> issue for this plateform.
> 
> http://launchpadlibrarian.net/12727159/10_expand_user_home.dpatch

Indeed.  It's mentioned here:

  http://sourceforge.net/tracker/index.php?func=detail&aid=1819737&group_id=66938&atid=516298

I'll try to remember to get to it soon, thanls.

-bill!

[Tuxpaint-devel] savedir option bug

[Francis G. <fra...@re...>]

Hi,

There is a bug with the savedir option, when specified in the
configuration file. Environment variables are not replaced by their
values. See :

https://bugs.launchpad.net/ubuntu/+source/tuxpaint/+bug/195868

I did a patch to fix this on Linux, but the function used is not
available for other plateforms. Does someone know how to do this on
Windows and MacOS?

At least, I think that the patch for Linux should be merged to fix the
issue for this plateform.

http://launchpadlibrarian.net/12727159/10_expand_user_home.dpatch

Cheer,

Francis

-- 
Francis Giraldeau, Ing jr.
Analyste Infrastructure
Directeur Qualité
Téléphone : (819) 780-8955 poste 1111
Sans frais : 1-800-996-8955
Télécopieur : (819) 780-8871

Revolution Linux Inc.
2100 King ouest - bureau 260
Sherbrooke (Québec)
J1J 2E8 CANADA

http://www.revolutionlinux.com

Toutes les opinions et les prises de position exprimees dans ce courriel
sont celles de son auteur et ne representent pas necessairement celles
de Revolution Linux

Any views and opinions expressed in this email are solely those of the
author and do not necessarily represent those of Revolution Linux

Re: [Tuxpaint-devel] [TuxPaint] Intensity/size value in API

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

On Wed, May 28, 2008 at 11:24:05PM +0200, foo-script wrote:
>  TuxPaint has no API function to get from user a value of intensity/size of magic tool. Would it be difficult to update the api a bit and create that possibility during this gSoC?
> 
>  I suggest to use same interface just like stamp have.

I think I'm ok with that.  We may want to be able to turn it off, for
simplification of the UI for younger children.  Also, obviously, each
Magic tool would need to tell Tux Paint whether the size/intensity option
even makes sense for it.  (For example, Mirror and Flip wouldn't need it.)

Additionally, I'd love to see the ability for Magic tools to be applied
to the entire image in one fell swoop.  For example, the Negative or Blur
tools could do this (otherwise, the user has to scribble all over the entire
image in one drag, without releasing the mouse).  Smudge wouldn't make
as _much_ sense.  Mirror and Flip already do this, so they wouldn't need
the option available.  And many of the drawing tools (Flowers, Rainbow, etc.)
wouldn't necessarily need the option.  (Of course, they _could_ do something
special -- e.g., 'fill the screen with flowers' or 'border the image in a
rainbow pattern', respectively.)

Gotta run... Thx!

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

[Tuxpaint-devel] [TuxPaint] Intensity/size value in API

[foo-script <foo...@o2...>]

 TuxPaint has no API function to get from user a value of intensity/size of magic tool. Would it be difficult to update the api a bit and create that possibility during this gSoC?

 I suggest to use same interface just like stamp have.

Best,
Adam

Re: [Tuxpaint-devel] wchar and BeOS

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

On Wed, May 28, 2008 at 05:55:09PM +0200, Schrijvers Luc wrote:
> Bill,
> 
> Looked at the code and even removed the OLD_UPPERCASE_CODE part in Haiku
> to check, looks like you were right. ;)
> 
> Haiku does not need the extra defined so && !defined (__HAIKU__) can be
> removed from the lines in both files. (still need to remember that even
> Haiku has a more uptodate (if not complete yet) possix system then BeOS
> had. ;)
> 

So what should I remove, then, exactly?  Is anyone using OLD_UPPERCASE_CODE
anymore?  (It merely picks which of two variations of the "uppercase()"
function in tuxpaint.c get used.)  I think it's old, crufty, unnecessary stuff
now, but I don't want to suddenly kill ports like non-Haiku BeOS...

Can you confirm whether I can just kill OLD_UPPERCASE_CODE all together?
(Anyone else using it?)

-bill!

Re: [Tuxpaint-devel] wchar and BeOS

[Schrijvers L. <Be...@sk...>]

Bill,

Looked at the code and even removed the OLD_UPPERCASE_CODE part in Haiku
to check, looks like you were right. ;)

Haiku does not need the extra defined so && !defined (__HAIKU__) can be
removed from the lines in both files. (still need to remember that even
Haiku has a more uptodate (if not complete yet) possix system then BeOS
had. ;)

Greets,

Luc

On di, 2008-05-27 at 19:18 -0700, Bill Kendrick wrote:
> Luc, I tried applying the BeOS-related #ifdef patch to Tux Paint's "i18n.c",
> but now I'm confused.  Based on the #ifdef stuff above (related to OS X),
> it looks like <wchar.h> gets included once on Haiku, and twice on BeOS.
> 
> (Whereas I think you want it _not_ on Haiku, and once on BeOS.)
> 
> Can you see what's in CVS right now and advise? :)
> 
> Thanks,
> 

Re: [Tuxpaint-devel] Mac OS X 10.2.8 support

[Martin F. <mf...@gm...>]

Bill,

Yes, go ahead and remove these ifdefs; we can always retrieve them from CVS
if we need to take another stab at 10.2.8 support in the future.  At this
point, building for 10.2.8 from a Leopard (10.5) machine is probably not
feasible (I don't think the 10.5 development tools even include a 10.2.8
SDK); the most reasonable way to get a 10.2.8 build going is to actually
build Tux Paint on a 10.2.8 machine.

Martin

On Wed, May 28, 2008 at 4:12 AM, Bill Kendrick <nb...@so...> wrote:

>
> So there's some stuff wrapped in "#if[n]def __APPLE_10_2_8__" in Tux
> Paint's
> source, but it seems supporting 10.2 has been difficult (from a "making
> builds"
> standpoint), so do people think it's safe to remove these tidbits?
>
> Martin?
>
> Thx,
>
> --
> -bill!
> bi...@ne...
> http://www.newbreedsoftware.com/
>

[Tuxpaint-devel] wchar and BeOS

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

Luc, I tried applying the BeOS-related #ifdef patch to Tux Paint's "i18n.c",
but now I'm confused.  Based on the #ifdef stuff above (related to OS X),
it looks like <wchar.h> gets included once on Haiku, and twice on BeOS.

(Whereas I think you want it _not_ on Haiku, and once on BeOS.)

Can you see what's in CVS right now and advise? :)

Thanks,

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

[Tuxpaint-devel] Mac OS X 10.2.8 support

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

So there's some stuff wrapped in "#if[n]def __APPLE_10_2_8__" in Tux Paint's
source, but it seems supporting 10.2 has been difficult (from a "making builds"
standpoint), so do people think it's safe to remove these tidbits?

Martin?

Thx,

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

Re: [Tuxpaint-devel] GSoC coding begins NOW!

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

On Mon, May 26, 2008 at 07:23:26PM +0100, Caroline Ford wrote:
> My student has exams until 5th June. I wouldn't expect anyone to work
> until their finals are over.

Yes, seems common.  Good luck to them! :)

<snip> 
> I also have a job now (yay!) so haven't been on IRC that much..

Congrats!


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

Re: [Tuxpaint-devel] GSoC coding begins NOW!

[Caroline F. <car...@go...>]

2008/5/26 Bill Kendrick <nb...@so...>:
>
> Today is the first official day of GSoC coding.
> Students and mentors - please contact each other today to make sure you're
> all on track.

My student has exams until 5th June. I wouldn't expect anyone to work
until their finals are over.

> BTW, I'm starting a new full-time job on June 5th, and will no longer be
> taking the long train commutes 2x/week (I did that for the past 1yr), so
> my availability on IRC and email will actually be a bit more erratic, since
> I won't have that time "stuck on a train with a laptop and nothing else to do"
> :^)

I also have a job now (yay!) so haven't been on IRC that much..

Caroline

[Tuxpaint-devel] GSoC coding begins NOW!

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

Today is the first official day of GSoC coding.
Students and mentors - please contact each other today to make sure you're
all on track.

Also, please note that Albert Cahalan's been making some modifications
to Tux Paint lately, mostly updates and simplifications to the Makefiles.

If you're working off of the main CVS repository from the SourceForge.net
'tuxpaint' project, be sure to "cvs update -dPC".

If you're working off of your own repository, please be careful when merging
back into the main CVS repo, if you do that soon.  (Hi, Mark :) )

Thanks, and good luck everyone!

BTW, I'm starting a new full-time job on June 5th, and will no longer be
taking the long train commutes 2x/week (I did that for the past 1yr), so
my availability on IRC and email will actually be a bit more erratic, since
I won't have that time "stuck on a train with a laptop and nothing else to do"
:^)

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

Re: [Tuxpaint-devel] Making a starter in Photoshop 10

[Gabriel G. <gab...@gm...>]

1- You have to go to the "Layers" tab and double click the Backgroung layer, 
then just hit OK in the dialog. (That makes the Backgroung layer a normal 
layer, i.e.: one than can be semi transparent).
2- Then you select the white background using perhaps the Magic Wand tool (W) 
(take care of the state of the "Contiguous" option in the tool options bar 
above).
3- Once you have selected all that you want, just erase it.
4- After that I'm not sure what you have to do, just because I don't know what 
type of image you need to end with. But if you need to build an alpha channel 
for it you can do so easily by Ctrl+clicking the (former) Backgroung layer 
and the using "Save Selection as Channel" from the Selection menu or the 
Channels tab (behind the Layers tab).

Hope this helps, if you still have doubts just let me know.

greetings,
Gabriel

p.s. Perhaps some options' names are not exactly as I wrote them, as I don't 
have Photoshop here right now.


El Jue 22 May 2008 18:08, Bill Kendrick escribió:
> Can someone provide some steps to make a Starter image (i.e., remove
> a white background and replace with transparency) using PhotoShop 10?
> I only know Gimp.
>
> Thx!

[Tuxpaint-devel] Making a starter in Photoshop 10

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

Can someone provide some steps to make a Starter image (i.e., remove
a white background and replace with transparency) using PhotoShop 10?
I only know Gimp.

Thx!

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

Re: [Tuxpaint-devel] cut-and-paste, copy-and-paste

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

On Thu, May 22, 2008 at 10:35 AM, Bill Kendrick <nb...@so...> wrote:
> On Thu, May 22, 2008 at 03:06:26AM -0400, Albert Cahalan wrote:
>> Choose a brush. A fat one is the default. Paint with it.
>> As you paint, a stamp is created. Nothing appears in
>> the main canvas as you paint. When you like the stamp,
>> simply select it and use it. It works like any normal stamp.
>> There is no "cut" operation, and the "copy" operation
>> happens implicitly as soon as you start to paint.
>
> So if you select too much, how do you unselect, to get the 'perfect shape'?

Most likely, you don't. Keep it simple.

It's possible to use the colors for this. Selections
can then be made with proper alpha, instead of
being binary.

> Also, I think for kids who are drawing something sparse -- i.e., most of
> their picture is background color -- a one-fell-swoop selection (like
> rect, ellipse or lasso), with the addition of a 'snap to shape' would be
> very useful for duplicating something they just drew.

Background removal can be done in any case.
You can't do it very well with snap-to-shape
because of the fringing problem.

Background removal could be done by default.
It could also be a button (or an undo button for
the default being to remove) to allow including
part of the background.