blog.kfish.org

My name is Conrad Parker, and I live in Kyoto, Japan. I work with Renesas in Tokyo, designing the Linux multimedia architecture for a new line of mobile processors; and for Wikimedia Foundation, working on Ogg integration for Mozilla Firefox. I am also working towards a PhD in Computer Science at Kyoto University. Free software projects include the Sweep sound editor and the Annodex media system, and various smaller ones that you can read about here.

Follow me on Twitter: @conradparker.

Tuesday, 25 March 2008

Release: xsel 1.2.0

XSel is a command-line tool for manipulating the X selection. This is a maintenance release, improving argument handling, documentation and X11 library detection.

Labels:

Sunday, 10 February 2008

Release: xsel 1.1.0

This is a story about the meaning of "version 1.0". A few weeks ago I released version 1.0 of xsel, a simple commandline utility for manipulating the X selection and clipboard. I chose to call it 1.0 after recalling a discussion with André Pang, about how the meaning of version numbers in open source software tends to differ from that in other software communities. For example, it is often advised not to buy the first version of a proprietary software product as it is sure to be buggy and incomplete; open source projects on the other hand often aspire to 1.0 being a major milestone, bug-free and fully-functional. The Windows and Mac freeware and shareware communities tend to follow a middle ground, content to release a useful but incomplete version 1.0, but thereafter avoiding the quick version creep that afflicts companies with marketing departments (and version-limited support contracts).

I'll argue that that middle way makes for more meaningful version numbers. Putting the label "1.0" on a release should be your way of saying that it's the first version that:

  • won't hose a user's system, and
  • hopefully does something useful.

Any version number less than 1.0 is sending out a signal that the software isn't quite ready yet; perhaps that you could lose or damage data by using it. Many people intuitively wait for version 1.0 before trying out some software, and this is fair enough. In fact, we need a way of warning that a project isn't ready for widespread adoption, that it could damage data, that the tarball is only out there so that other people can grab the code and help fix bugs. That's what version numbers less than 1.0 mean.

After 1.0, you can keep adding features and bumping the version number, working towards version 2.0 which perhaps does useful things in a different way. And from 2.0, onwards to 3.0 and beyond; integers are cheap. The important thing is not fall into the trap of thinking of 1.0 as some kind of asymptotic upper bound representing the perfect release.

Back to xsel. At first I wrote up release notes as version 0.9.7, but then then remembered that discussion with André and realized that it should really just be 1.0. More to the point the previous release (in July 2001, which went five years without a bug report or patch) should have been 1.0. So yeah, it was a good feeling to just write "1.0" and send it out.

The morning after releasing 1.0 I got a report from someone who couldn't get it to compile -- turns out they didn't have the X11 development libraries installed, and for some reason I had commented out the checks for that in configure.ac while testing something or other a while ago. As a result, the configure script wasn't check for its only dependency. I considered doing a canonical 1.0.1 (LOL) release. Within the next day, though, I got a report about how to fix handling of COMPOUND_TEXT, an archaic way of handling international text (since superceded by UTF8_STRING). And there follows the next lesson (as berated by Raster): random bug reports stream in after a release, not before. Erik de Castro Lopo is up to his 20th pre-release of libsndfile 1.0.18; each pre-release he gets bombarded with reports.

Anyway, the post-1.0 bug reports have died down, so today I'm releasing version 1.1.0 of xsel. "This release adds basic support for COMPOUND_TEXT and fixes a configuration bug". And I'm still waiting to hear good uses of xsel --append and xsel --follow.

Labels:

Sunday, 13 January 2008

Release: xsel 1.0.0

XSel is a command-line program for getting and setting the contents of the X selection. You can use xsel in shell scripts and desktop keybindings, so that the contents of the X selection are available to command arguments:

mozilla --remote "openurl(`xsel`)"

This release adds UTF-8 support and fixes various bugs. The last version of XSel was 0.9.6, released sometime around 2001. It may have been the first version also. For some reason a bunch of patches came in recently, and I've had the joy of revisiting this project.

For old time's sake, my thoughts on ICCCM. (Warning: explicit language). Back then I made a point of implementing as much of that crack as possible. You can even tell applications to delete their selected text:

  • To delete the contents of the selection: xsel --delete

(This really works, you can try it on xedit to remotely delete text in the editor window).

This time around, of course, nothing does what the docs say anymore. So we ignore the details in the 2001 proposal for Inter-Client Exchange of Unicode Text and just grunt atoms at the selection owner until they yield all their secrets. And now, finally, xsel works on Japanese.

People have come up with some interesting uses for xsel over the years, but nobody has yet come up with a nifty use for the following options:

  • To append to the X selection: xsel --append < file
  • To follow a growing file: xsel --follow < file

Any ideas?

Labels: