Wandering Thoughts: Recent Entries For 2006/07/24

Link: Linguistic blindness illustrated

If you can answer this, you are not paying attention is a nice illustration and discussion of the importance of thinking about what you're writing in prompts and questions in software. Also interesting is a followup entry on why everyone is so against using 'yes' and 'no' for answers in dialog boxes.

(From Daring Fireball.)

A brief history of cut and paste in X

Here's a brief history and explanation of how cut and paste works in the X Windows system (to give it its formal name), prompted by this blog entry with the entirely reasonable gripe that selecting something in a program and then exiting the program causes the selection to disappear.

There are two separate cut and paste mechanisms in X, from two separate eras: the cut buffer and selections. The cut buffer is the older mechanism, and works by having programs store the cut data into an X property on the root window, which you can see directly with 'xprop -root CUT_BUFFER0'. (Technically there are eight or so cut buffers, but almost no one uses anything except the first one.)

The cut buffer has some limitations:

• it doesn't handle large amounts of data, because it stores things in X properties.
• it only really handles text, and text without character set information at that.
• you can only make the data available in one representation, when it may have several possible ones.

These were fine as long as the X was mostly used to run xterm and xclock (to swipe a slam from the Unix-Haters Handbook), but not so good when people started trying to do more sophisticated things. Enter selections.

Selections solve the cut buffer limitations by making the program that generated the selection hold onto the selection itself. When other programs want to paste something, they talk to the holding program directly to get a copy, and negotiate things like what format it's going to be in.

The drawback of the selection model is what Martin Krafft experienced: if the program that set up a selection goes away, so does the selection, because no one else has a copy. (In fact the creating program can make the selection go away any time it feels like, and often has to take extra steps to take a private copy just for the selection.)

As a pragmatic matter, any program that selects text should export the selection into the cut buffer and anything that can paste text in should read from the cut buffer if there's no current selection, because that avoids most of the problem. Unfortunately there has been something of a movement for ignoring the cut buffer as 'obsolete', so things like Firefox and gnome-terminal never go near it.

(A more complete technical explanation is in Jamie Zawinski's X Selections, Cut Buffers, and Kill Rings.)

Sidebar: selections and the clipboard

The clipboard is effectively a second selection; it uses the same mechanisms and also goes away when the owning program exits. What shows up in the clipboard versus what is just a plain selection depends on the application, but the general rule is that copying or selecting something explicitly will make it into the clipboard instead of a mere selection. For most purposes you can ignore the difference.

The xclipboard program keeps a copy of the clipboard contents, which can sometimes be convenient. It also makes a handy text window to scribble stuff in.

(A similar xselection program is possible, but I don't know if anyone's already written it. It might cause significantly more X traffic and CPU usage, since programs change the selection a fair bit more than they change the clipboard.)

Walking away from Slashdot: a story of design

A while back I wrote about the two faces of RSS, in the process of which I held up Slashdot as an example of a site where I preferred the actual site to the syndication feed by a large margin, and why.

I have to change that, because Slashdot has lost me as a regular visitor to their website, and what Slashdot stuff I read nowadays is almost entirely through their RSS feed. It's for the traditional reasons: a website redesign that actually injected 'design'.

Slashdot used to show me the article text (the most important thing) in my preferred font at my preferred text size. In the redesigned Slashdot, they don't; instead they commit the most common problem of setting the important text in a reduced text size. They also force their text to be set in sans-serif (whatever that is in any particular browser), instead of my default font.

I can fix a too-small font size, but the problem is I have to keep fixing it every time around. And that's been enough to push me away, and since the Slashdot RSS feed is not really a good substitute I read a bunch less Slashdot these days. (Some people would say that this is about time, or long since overdue; personally it makes me a bit sad.)

(I am not interested enough to do something with Firefox's GreaseMonkey. Possibly some user CSS stylesheet magic would do it too; perhaps this will be an incentive to learn about that particular obscure Firefox feature. But really, Slashdot has persuaded me not to care.)

Slashdot isn't by any means alone in this sort of stuff; people do this to their websites all the time. At one level I can say I have no idea why, but at another level I suspect I do: people feel that the browser defaults are bad. (Are they? I don't know.)