Tuxpaint GUI testing with xautomation

Tuxpaint could be a poster child for l10n. It has translations now for 68 different locales. The large number of locales poses somewhat of a problem for testing1.

Tuxpaint 0.9.16 just released. During the release preparation, the manual testing of all of these locales drove me nearly insane. So to help out next time, I created the following bash script using xautomation2, imagemagick and xprop (from xbase-clients):

root_geometry=`xprop -root _NET_DESKTOP_GEOMETRY |cut -d= -f2`
root_x=`echo $root_geometry |cut -d, -f1`
root_y=`echo $root_geometry |cut -d, -f2`

capture_tuxpaint () {
   tuxpaint --startblank --nolockfile --lang $1 --640x480 --windowed --nosound &
   sleep 1
   xte "mousemove $xc $yc"
   xte "mouseclick 1"
   sleep 1
   xte "key Escape"
   sleep 2
   import -silent -window "Tux Paint" $testname-$1.png
   xte "mousermove -120 -40"
   xte "mouseclick 1"

for lang in `tuxpaint --lang help |awk '$1~/^[[:lower:]]/ {print $1}'`; do
   capture_tuxpaint $lang

I’m not entirely happy with it, but it’s at least a starting point. Ideally, I’d make .pat files to use with visgrep to find coordinates for the button images instead of hardwiring the approximate button positions. Also, the script needs a companion script to configure the system for testing (i.e. perform the locales configuration and install all fonts).

Here are the resulting screenshots which show up a few problems with the translations. It looks like the quit dialog strings have been updated since they were first translated, so now we need retranslation for several languages. Also, there are some languages, like Swahili and Klingon, for which there are no locales in glibc in Debian. I’ll have to talk to the glibc maintainers about that. And for that matter, I don’t even know if a DFSG-free Klingon font exists.

In any event, I’m delighted with the results, and look forward to using xautomation more for GUI testing.

1 For one thing, several languages require special fonts. For another, there is no way to get tuxpaint to tell you what locales it supports. Granted, there is --lang help, but this is a crude approximation, as the mapping between language and locale is arbitrarily hardwired (which hmh on #debian-devel irc pointed out to me is just plain wrong). It doesn’t help me at all in the arduous task of configuring glibc locales so I can test them. For that, I need to look at i18n.c.

2 I tried using xmacro at first, but xmacrorec just made my pointer jiggle back and forth. It seemed like it was updating the position for a short distance, and then X was resetting it back to the former position of the pointer. Some strange interaction with my window manager, perhaps? But ultimately I am happier with the xautomation approach anyway.

5 Replies to “Tuxpaint GUI testing with xautomation”

  1. Tux Paint moves the mouse to the center of its window after the splash screen is dismissed, so that may have been an issue with xmacro…?

    Thx for your hard work, Ben!


  2. Hi Ben,

    I remember you asking about Chinese fonts for tuxpaint a few days ago, and now I notice that you only have one screenshot for Chinese while there are two variants — zh_CN (simplified) and zh_TW (traditional). The one shown here is simplified. Is the missing traditional Chinese screenshot just a oversight?

    Thanks for the work, it was fun to see all those languages.

  3. Ming,

    It’s there, but just not in the order you expect because my script returns “chinese” for simplified Chinese and “traditional-chinese” for traditional Chinese, so the names do not collate next to each other.

    Ideally, I’d iterate over all supported locales instead of all supported languages, except as I pointed out in the article, tuxpaint doesn’t provide a way of listing all of the locales it supports.

    Here is the screenshot for “traditional Chinese”:http://syn.theti.ca/~ben/tuxpaint_tests/61.html.


  4. Oh, I see. Guess I’ll remember to see all screenshots before commenting next time. 🙂

    It’s interesting to see the two Chinese variants are taking quite different approach in translation. (In a sense, you can use the same translation for both of them, only written in two different scripts.) It also seems to me that traditional Chinese has a much better and apparently more completed translation.

Comments are closed.