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):


#!/bin/bash
testname="tuxpaint"
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`
xc=$((root_x/2-1))
yc=$((root_y/2-1))

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
done

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.

Adequate mobile text editing device

Ideal mobile text editing device redux

As I read the responses1 to my search for the ideal mobile text editing device, reality began to set in. The heating season is now upon us, and even used technology meeting my criteria would likely exceed my stated budget. Furthermore, I’d risk replacing my current issues with a whole new set of issues and end up with a less-than-ideal mobile text editing device.

So I have rethought the problem and have decided it would be best to work on with what I have now while I wait for this ideal device to arrive on the market.

Keyboard

While I can’t change the keyboard of the ZR-5000, with a practiced lighter touch on the keys I can, in fact, touch-type passably well. It has served me well enough to draft several blog articles so far.

Software

Although not up to the high standard set by Vim, for quick note-taking, I don’t really need a fancy editor. My thoughts flow directly through my fingers into the device with only light editing. Cut-and-paste, motion keys and delete are the bare essentials. Anything more is a frill.

Synchronization

I do have an ACTiSYS IR-200L infrared dongle for my PC. The trouble is, although this is supported in Linux using IrDA, the ZR-5000 insists on speaking ASK-IR which is not supported.

There is a Windows-only program, ZRLink, which might work. I’ll try it either on an XP system at work, (… mixed reviews out there as to whether it will work on recent Windows,) or under Wine. I can get the dialogs to display properly on Wine, but I have my doubts about whether serial emulation works. My initial tests at home under Wine indicate it doesn’t. (Could #277618 have something to do with this?)

There is a 15-pin serial connector on the device, but I have no cable for it. And there’s a PCMCIA slot, but compatible devices are likely limited to older, harder-to-find components: either a 2M CF card or a modem card. While I have the latter, it exceeds the power available from batteries and I have no DC adaptor for the unit.

Perhaps I overrate synchronization anyway. My best articles are rewritten from scratch more than once.

Summary

Living in an embarrassingly technology-rich country, it is too easy for a geek like me to convince himself that his gadget cravings are needs whereas, in fact, there is still plenty of life left in the devices he already has. After all, my venerable ZR-5000 was given to me by a fellow who figured if any one of his friends would still be able to use it for something, it would be me. Well, I won’t let him down. I’ll stick with it and make it work.

There is one virtue of this device I doubt if any modern device of the same form factor can match. After a week of daily use, I still haven’t had to change the 2 ordinary AA NiMH batteries. Top that.

1 Thanks, everyone, for your responses. Although there were the inevitable few that mentioned modern devices way over my budget, and I’ve decided now to stick with the ZR-5000, your suggestions did help me bring the real issues into focus.

Apt verb

In the English language, it is so trivial to create new words. In no domain is this quite so evident as the world of computers.

Thus, informally amongst Debian users, you’ll often hear “apt-get it” or simply “apt it” which has the virtue of being equally apt a term for using aptitude. Now, I have no problem with people using these verbs. They’re precise, if a bit geeky. But really, shouldn’t there be a more general verb to cover this activity?

Back when apt was new, and nobody else was installing packages this way, the lack of a general term made sense. But these days, in certain user communities, you might hear “yum it” instead. How many variants does the English language need? One per apt-like installer?

Compare this with the evolution of instant messaging. Back when ICQ dominated the field, “ICQ” was synonymous with instant messaging. These days, although you might occasionally still hear people say “ICQ me” or “Jabber me” (where the protocol is important, because both participants must have access to that specific service) we can more generally say “message me,” encompassing in one fell swoop all possible protocols. Or if you prefer, the awkwardly geeky but more precise term, “IM me” (though arguably slightly less useful than “message me” because it seems to exclude irc, the king of all chat systems).

So, what’s the equivalent verb that means “conveniently installing software from one or more software repositories by merely asking for the package by name”?

My mind draws a blank.

Ideal mobile text-editing device

Dear Lazyweb,

I’m looking for a small, (easily fits on my lap on the cramped seat of a bus,) inexpensive, (around $100 CAD,) mobile text-editing device with a 90%-sized keyboard and decent battery life that runs an open source OS and Vim, and that I can sync to my desktop system.

My first mobile device was a NEC PC-8201A, circa 1984. It ran on 4 AA NiCad batteries which I hardly needed to change more than once a week. At the time, it was my ideal mobile notetaking device. Its near-full-sized keyboard, Wordstar-compatible text editor, terminal program and serial interface allowed me to take notes which I would sync to my father’s Mac at home or to the VAX at the university.

Today, my mobile computing needs have hardly changed: text editing is almost all I do. I don’t ask for much of a display, but as an 80 to 90 wpm touch-typist, I won’t settle for anything less than a near-full-sized keyboard. I’d prefer a system that runs Debian, and Vim is a must. Some means of easily synchronizing the device with my home system is necessary: PCMCIA wireless-B would be ideal, but is not a must-have.

At the moment, I’m using an old Zaurus (not Linux-compatible) ZR-5000 which has good battery life but a very cramped keyboard, poor software, and no functional means of synchronizing the device to my PC. OK for jotting down quick notes, but frankly, I’d rather have my PC-8201A back again. I could at least type on it and sync it across the serial cable.

I took a brief look at various Psion models, but they appear to be near-impossible to find. The HP Jornada 720 looks intriguing. And the NEC Mobilepro 780
appears to be another possibility. Have I overlooked anything?

So, suggestions please.

Ichthux and Ubuntu CE: Why two projects?

Barbicane asked me the other day: “Why Ichthux and Ubuntu CE? Why not consolidate efforts?”

As much as I’d like to see Ubuntu CE succeed, I believe they are headed down a path that will make it difficult for them to survive if they continue. In this thread (see Google cache since the forums
seem to be having problems today) Jereme severely understates the differences in development philosophies that
keep us apart. One key difference is more fundamental than just using metapackages instead of scripts.

As I wrote about earlier, the approach Ichthux has chosen is to be a Custom Debian Distribution (CDD), working within Debian and Ubuntu to configure those distributions
for the needs of Christians to meet their various needs. This is incompatible with CE’s approach, which uses scripts to tailor an Ubuntu system. This approach risks violating the integrity of the packages being modified, and makes each system upgrade an adventure for the user. What you end up with cannot truly be called an “edition” of Ubuntu at all, but is more accurately described as an Ubuntu derivative. Derivatives are not easily sustained because they are always struggling with staying in sync with the parent distribution. Ubuntu itself is a derivative, but it has an impressive amount of infrastructure with a lot of manpower behind it to ensure that the branching and merging process doesn’t get out of control. I don’t see how the much smaller Ubuntu CE development team will manage to accomplish anything significant using their current approach without being crushed by the maintenance costs of their customizations.

Another difference, perhaps more readily apparent to end users, is what’s included in each distribution by default. While CE has chosen the Gnome desktop, Ichthux has gone with KDE. With each new release of Ubuntu CE, it seems what is stressed the most in their release notes is “what’s included”. Well, I just can’t see how that’s terribly important. Debian and Ubuntu both have a vast amount of software available, and both make it easy for users to make choices. If a user wants to add another application, it’s often just a few clicks away. It’s
not nearly as important to have these installed by default as it is to ensure that the packages we do include are as solid and well-integrated with the system as possible.

To this end, Ichthux makes use of its Debian and Ubuntu developers to ensure that each package included is kept in good shape from release to release. This means addressing bugs and wishlists that matter to our users, improving those packages not just for Ichthux, but for Ubuntu, Debian, and where those fixes flow back upstream, the broader community of Christian FOSS users everywhere. This is the real work of Ichthux: not just the production of a livecd, nor merely tweaking the default selection of packages we include from one release to the next, but to be actively involved in the Christian FOSS developer and user community. Our greatest successes will
not be in the degree to which we differentiate ourselves from other Linux distributions, but rather how well we’re listening to what Christian FOSS users are saying they need, and how broad we can make our solutions. We can’t afford to be a niche distribution working off in a corner on our own pet project. That would be a terrible waste of our energy. We’re dreaming big: we want every Christian Linux user to be able to benefit from our work.

TODO or not TODO

I’m reviewing my next actions: dozens of worthy projects waiting for me to do. But I just can’t seem to get moving on any of them. What’s keeping me back? What is so hard about getting things done? Especially with respect to the more rewarding tasks on the list, it’s a mystery that I fail to act. It should be easy.

I’ve fretted over this problem for years, yet I’m no closer to an answer today at age forty than when I first discovered my dubious skills many moons ago as a procrastinator extraordinare. Surely all that I need to do is stop worrying and just act—act, and continue to act until to get things done is as natural as breathing.

Oh, so simple! So easy to say! I fear I am caught in a cycle of anxiety and inaction that defeats me before I even begin. Faced with my list of next actions, I inexplicably feel anxiety about it with something like the force of physical pain. I balk. I seek out some numbing diversion to get relief: anything but whatever’s at the top of my list.

But I know I mustn’t nurse this fear, or it will grow. I will not escape by focusing on how hard it is. So I resolve to nurture hope, to act and not doubt.

TODO: Pick any next action. Do it! Repeat.

Ichthux, a joint Debian/Ubuntu project

Whew. Ichthux has released, and now I can breathe again!

When I joined the Ichthux development team, they had produced their “proof of concept” release as yet-another-Knoppix-remaster. At that time, I encouraged them to move away from tacking their work on as a derivate of a derivative and instead become a CDD. I argued that as a CDD Ichthux would last, while as a Knoppix-remaster, it would just be another marginal custom livecd that went nowhere. They got the message. So you may well be surprised to hear our first release is based on Kubuntu, and not Debian.

So, what’s the story here? Have you defected?

Nope. It just happens that most of the team ended up being actively involved in Ubuntu development. Also, when we first started casting about for the best way to package a livecd/install disk, it seemed to us that Ubuntu already had a head start on this.

What about being a CDD? It looks to me like that idea has fallen by the wayside.

Nope again. We’re a joint team now, and though we’ve started out with Ubuntu, we’ll be pushing changes back into Debian. The goals of a CDD are well understood by the whole team: to best meet the needs of our users, we design the system to mesh well with the parent distributions, not forking and making a derivative, but working inside those distributions to improve them for our particular subgroup of users.

Hold on now, aren’t you contradicting yourself? A CDD’s development is all within Debian, but Ubuntu itself is a derivative, and what’s worse, Kubuntu is a derivative of a derivative! Aren’t you right back where you started?

Well, on the last count, you’d be wrong. Kubuntu is not a fork. And as for Ubuntu being a derivative, well, sure it is. But the Ubuntu/Debian relationship is different from other derivatives, and although there is friction, I’m enough of a crazy idealist to believe a joint Debian/Ubuntu CDD is quite doable, benefits both projects more, and serves our users better than if we were to split up and each go work on our own.

Keeping free software projects fun as they grow

On the whole I agree with Erich. Subprojects are key to preserving positive energy as a free software project scales. But I wouldn’t say the ill effects suffered by projects as they age is just “a matter of size”. And I wouldn’t de-emphasize the importance of guidelines like the Ubuntu Code of Conduct and the Debian Community Guidelines in countering those effects, though I’d agree they do not provide immunity by themselves.

Ubuntu benefits from the Debian social experiment having started first. So the people involved have the opportunity to learn from and improve on earlier efforts while their project is still young. The DCG and CoC are no panacea, but they are a clue that lessons are being learned; deliberate effort needs to be made to keep work fun, especially as a project grows and people begin to lose touch with each other. Putting these lessons into practice isn’t always easy, but I think it would help if as individual developers we’d reflect more on how we interact within our projects and work on making improvements. I appreciate the personal guidelines Erich shared and will adapt them to make them my own.

Plumbing the depths of cdbs

On #debian-games we were discussing today how opaque cdbs is for those who aren’t intimately acquainted with its inner workings. I want to be able to easily see, at least at the level of detail visible in a purely debhelper-based rules file, what’s going on inside just by running make itself, e.g.

debian/rules -p | grep -v ^# | grep -B1 dh_

Here’s a small excerpt of the output when run on ri-li:

binary-install/ri-li::
        dh_installdocs -p$(cdbs_curpkg) $(DEB_INSTALL_DOCS_ALL) $(DEB_INSTALL_DOCS_$(cdbs_curpkg))
        dh_installexamples -p$(cdbs_curpkg) $(DEB_INSTALL_EXAMPLES_$(cdbs_curpkg))
        dh_installman -p$(cdbs_curpkg) $(DEB_INSTALL_MANPAGES_$(cdbs_curpkg))
        dh_installinfo -p$(cdbs_curpkg) $(DEB_INSTALL_INFO_$(cdbs_curpkg))
        dh_installmenu -p$(cdbs_curpkg) $(DEB_DH_INSTALL_MENU_ARGS)
        dh_installcron -p$(cdbs_curpkg) $(DEB_DH_INSTALL_CRON_ARGS)
...

OK, it’s a bit crude and misses a lot of interesting details, but it is a starting point that can be tweaked to zero in on whatever parts interest you.

XPilot change of upstream growing pains

XPilot development has changed hands over the past several years. While the
original website at www.xpilot.org continues to be run by the original
developers, XPilot-NG (xpilot.sf.net) is where all of the new development has
been happening. But xpilot.org still performs an important function for the user
community: they run the meta servers1 that list all public xpilot servers around
the world.

Recently, we (the XPilot-NG developers on #xpilot at irc.freenode.net) noticed
quite a number of uncontactable servers popping up on the meta servers. This is
annoying, to say the least. Users don’t know they can’t connect until they’ve
tried (unless they’ve bothered to try pinging the server first) and besides
which, having all those “junk” servers in the list makes it harder to locate
contactable servers.

Now, naturally, we wanted to know where all of those servers were coming
from, and why now, at this particular time? I knew my Debian package (and
presumably any derivatives) do not report to the metaserver by default. Any
admin starting an XPilot server would have to explicitly configure it to do so,
so the incidence of uncontactable Debian XPilot-NG servers should remain
relatively low and have a constant growth rate. Then I found the Fedora
package, and started poking around inside. After a shallow review of the
package, I concluded there was a good chance it was the culprit2, especially
since it recently (FC5) had an init script added. Such a bug, coupled with the
relatively recent release of FC5, would account for the sudden spike in number
of permanently running non-contactable XPilot-NG servers.

Bingo! I found some helpful folks at #fedora-games at irc.freenode.net, including the XPilot NG maintainer, which
led to filing this
bug
. I subsequently invited the maintainer over to #xpilot and had a nice time introducing him to the other upstream devs and chatting about our current issues.

Ultimately, we know we need to fix the problem at the metas, but in the meantime, I am pleased to have established contact with my counterpart in the
Fedora project, expanding the diminishingly
small XPilot developer community by one.

1 They deliberately never released any source code for those metas
to try to keep the user community unified at the centralized servers. While I
see the reasoning behind the decision, given the problems we’re facing now,
it’s clear the XPilot community would be better off with meta server source that
is actively being maintained.

2 Admittedly two problems with the +reportMeta option upstream set us up for this problem. First, counterintuitively, +reportMeta disables reporting to the metaserver (following the rule ”+” negates the meaning of an option starting with ”-”). Second, -reportMeta is a stupid default. Most people starting servers are behind firewalls these days, so unless they consciously decide to make their server public, making the corresponding adjustments to their firewall, the option should not be set (not to mention the security implications of making a server public by default).