Tuxpaint activity is bloated

[Albert Cahalan]

FYI, the Tux Paint port is mine. I have CVS commit rights to
the main Tux Paint code base. Probably 5% to 10% of the code
is mine.

Mitch Bradley writes:

> The filesystem layout for the tuxpaint activity has a lot of
> boilerplate that contributes to it taking up a lot of space on NAND.
> In some NAND images from Uruguay that I analyzed today, over 5000
> directory entries - nearly 50% of the total number of dirents in /home -
> were from tuxpaint.

This is unsurprising. Aside from minor packaging troubles,
the issue is that Tux Paint is simply not a bare-bones paint
program. If people want bare-bones, they use Paint instead.

In terms of total space, a large and growing problem is i18n
of *.ogg files that provide descriptions of the clip art.
Tux Paint supports 4 or 5 dozen languages, of which a half
dozen have audio descriptions.

> For example, there are 200+ CVS subdirectories, each containing "Root",
> "Repository", and "Entries" files.  Many of the CVS directories are in
> localized subdirectories, which also contain many copies of dirents or
> localized versions of files likes COPYING.txt, AUTHORS.txt, etc.

I've been doing massive Makefile changes to deal with this properly.
The *.xo is far from the only thing affected; I have these files in
my /usr/share/tuxpaint directory. The only reason you don't see them
on a regular Linux distribution is that the package maintainers
delete them after the build.

> One subdirectory hierarchy is named "org.tuxpaint.sugar-is-lame\".
> That is unprofessional.

Hey, more evidence! Tux Paint does not ship with any such directory,
and does not ask for such a directory to be created. Tux Paint has
no use for such a directory. Please get sugar to stop being lame.

The "sugar-is-lame" string comes from a value that activities are
required to provide, even when the value is of no use. Activity
authors are being forced to provide a random string that is of no
use to the activity, so of course I provided one. The fact that I
was **forced** to provide this string is of course evidence of the
fact that sugar is in fact lame.

Not that any more evidence should be needed of course, but I hear
that the "-" character has now been made invalid. The allowed set
of characters was undocumented, has recently changed (breaking an
existing activity) without notice, and is still undocumented AFAIK.
I think we can conclude that yes, sugar is indeed lame.

IMHO, "unprofessional" would be text that includes the appropriate
level of profanity. (which, in this case, goes to 11)

> The activity itself appears to somewhat popular, at least based on its
> presence on all of the Uruguay NAND images that I analyzed.  If it is
> indeed popular, perhaps it would be worthwhile to optimize it for XO to
> reduce the footprint.  In addition to removing boilerplate that the
> children won't look at, one possible optimization would be to collapse
> the many files in TuxPaint.activity/share/tuxpaint/stamps/ into a few
> archive files, thus reducing the filesystem overhead.

Archives sound like a bad idea. Fast random access to those images
is kind of important.

Just what kind of overhead are we talking about here? If jffs2 is
much worse than an archive, then clearly jffs2 fixes/replacements
should be a priority. After all, jffs2 affects all activities.