Tux Paint

Or:
Epiphanies, frustrations, l10n, cross-platform considerations,
web scripting, automation, project management,
and other things you need to worry about
to create a popular and award-winning software replacement for crayons

Bill Kendrick
Lead Developer, Tux Paint

Sonoma State University
September 11, 2008

Background

• Started in 2002
• C using Simple DirectMedia Layer (SDL)
• Filled gap in Linux for "kids drawing software"
• Inspiration: PalmOS, Atari 8-bit, Commodore 64

Today:

• 25,000+ lines of code*
• Windows, Mac OS X & BeOS ports
• Included on ASUS EeePC
• Officially in Ubuntu, Debian Linux
• Packages for Slackware, RedHat Linux, BSDs, etc.
• 80+ languages
• Millions of downloads

* Generated using David A. Wheeler's 'SLOCCount'

Project management

• Tech support for non-techies (usually email me directly)
• Keeping track of who's done what and who's still involved
• Website upkeep
• Mailing list administration
• SourceForge bug tracker
• File releases
• Press release writing/editing
• Announcements to various software sites, magazines, etc.
• Keeping an eye on news and blogs (thanks, Google)

Google Summer of Code (all of Tux4Kids)

• Needed to round up mentors
• Way too many students applied
• Keeping students going and on track proved difficult for some of us (cough)
• By the end: lots of great new stuff... but tons of integration and polish needed before a new release!
• Payment craziness (don't want tax hit!); trying to join SPI

Cross-platform considerations

• More people with "real lives" that I need to depend on
• Numerous Mac devs came and went
• Windows OS variations and bugs cause headache
• Development for older OS X on newer OS X is troublesome
• Many others are one-offs. Sorry, can't support/update it myself!
• Pro: #ifdef helps keep older platforms supported.
• Con: #ifdef causes nightmares.
• SDL + hand-coded UI is easy to port.
• SDL + hand-coded UI is hard to maintain, make accessible, localize easily...
• Printing, system integration, packaging, etc. is beyond scope of SDL. Each port does it differently.

l10n ("localization")

Translating the program

• "#ifdef SPANISH" not so popular... :^)
• Quickly steered towards the right & popular way: gettext
• Basic TrueType Font support works for most languages. Arabic? Not so much.
• Right-to-left UI is still on the to-do list.
• SDL input system not wired for i18n. We rolled our own Input Method system. (Thanks, Mark!)

Translating the website

• Old way:
  • Pulldown form field + web cookie = language choice
  • index.phps use include()s to grab appropriate file (e.g., "trans/es.php")
  • Translators create the include()ed ll.php files; edit carefuly (or not >:^( )
• New way: (pending!)
  Translators love PO files, and PHP supports gettext(), so...
  • Wrap strings in gettext(), run xgettext to generate POT for website
  • Translators create PO files, as usual!
  • Negotiate locale with browser via "Accept-Language" HTTP header
  • Provide pulldown + cookie too, just in case!

Translating Stamps

• Making new stamps is easy; create a PNG. Describe it in a TXT file.
• Maintaining 100s of TXT files in the project was hard. Python to the rescue. Convert TXT to POT and PO. Update POs. Convert back to TXT.
  1. Shell script runs...
  2. ...Python script that examines all TXT files to find any new strings, or updated English
  3. ...then runs "msguniq" to create a new POT file
  4. ...and runs "msgmerge" on each PO file to bring them up to date
  And...
  1. Shell script runs...
  2. ..."msguniq" on each PO file
  3. ...then runs another Python script to create new TXT files based on the POs
  Nice fat CVS commit attempt at the end.

Web scripting

PO status

1. Shell script grabs latest from CVS, copies POs to FTP site for quick download by translators, runs another script...
2. ...processes PO files to determine percentage of translation, drops results into a tab-delimited TXT file...
3. ...PHP code on website sucks PO translation percenatages in, creates nifty, sortable table with graphs on website.
4. Result: tuxpaint.org/help/po

Website look-and-feel

• Basic PHP include()s pull in navigation bar and look-and-feel
• Helper functions for wrapping around screenshots
• Gallery system driven by TXT file full of authors, and TXT file full of images

(I avoided depending on a Real Database(tm), to keep the site portable.) All home-grown, all hand-maintained. Equals: I do it all myself!

Frustrations

• Weird school network setups I have no experience with
• Trying to have a release deadline, but finding all of my porters are busy
• Unacceptable content introduced
• Worrying that the website is information overload
• Questions from users who give no details ("an error happened"... when? during download? launch? while running? what error? what system are you even running it on? what version of Tux Paint are you using?)

Epiphanies

Double-shot mocha + bike ride = brainstorm.

• GIMP utilizes plugins, why not Tux Paint?
  (Plugin-based "Magic" tools and API)
• Squirrels bounce across the road... why not bounce across Tux Paint?
  (Animated and directional brushes)
• Inkscape has calligraphy... why not Tux Paint?
  ("Calligraphy" Magic tool: the quicker you draw, the thiner the line)

Conclusion

1. Create Tux Paint
2. ???
3. Profit!

Bill Kendrick <bill@newbreedsoftware.com> graduated from Sonoma State University's Computer Science department in 1998.