TuxPaint woes

[Albert Cahalan]

Mikus Grinbergs writes:

> There are people like me who like TuxPaint better than Oficina.
> However, to run TuxPaint, users of current Joyride need to
> re-install SDL_mixer and libmikmod.

I hope you've filed a bug to request that those libraries
be put back.

I could use libpaper as well; the alternatives are that I drop
printing support or dig my old printing code out of Tux Paint's
CVS history. You may guess which is more likely.

> seems to start slower than it did

Without any profiling data, I'm going to point the finger at all
the Python-specific hacks. In particular, keeping an interpreter
running to fork off children is an evil memory-sucking hack.

> I realize there is a serious shortage of resources.  But should it
> be up to the Activity developers (or in this case, those who first
> "fitted" the software to Sugar) to keep supporting their submission
> as the Sugar/operating_system platform keeps evolving ?

FYI, I'm one of the core Tux Paint developers. (top 5 at least)
Maybe one person knows Tux Paint better than me, and he's quite
busy too. (new baby, California-style commute, etc.) He just got
an OLPC, and he reports that Tux Paint runs without any problems.

Changing the platform breaks stuff. If that means that lots of kids
(directly, or via school choice) will refuse to upgrade, oh well.
You're not supposed to break stuff.

BTW, there really shouldn't even need to be a *.xo for Tux Paint
or any other program. There are some moderately standard ways to
handle the problem of installing a package on a Linux system and
creating menu entries. Had these not been gleefully abandoned,
all sorts of things would just work.