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. _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
