Reply All

Here's a cool feature of Apple's Mail I've never noticed before: "Reply" and "Reply All" toggle. This means that there's not such a strong reason to remove the "Reply" button from the toolbar as there is with, say, Outlook. If you chose wrong, it doesn't matter. You can keep changing your mind right up until you hit send, with no manual typing or removal of addresses.

That explains the otherwise mystifying presence of a "Reply" button on the toolbar for the window you're writing a reply in!

Dance Dance Revolution Tekken

It's not as much fun as real sparring, but playing Tekken on a dance mat is better than nothing. It would be much better if there was a stronger connection between your movements and your character's movements, if you couldn't knock someone out with a punch to the knee, and if there were a referee.

It's really frustrating to not be able to do things in the game that you can do in real life, and being able to do things in the game that I can't do in real life doesn't make up for it. If only Ling Xiaoyu lived round here.

I think that's the first time a computer game has made me sweat.


Another reason not to bother with Ant...

On my dual G5, I can build GNU make 3.80 from source in 4s. Which means I can build it from source every time I run it and still be pretty competitive with Ant's performance.

Of course, it sucks that I have to build from source to get a version of GNU make released in 2002, but I filed a bug report with Apple for that earlier this year.

Also built from source so far: GNU grep 2.5.1 (which thanks to the current state of GNU grep, I had to get from Debian!), Jikes 1.22, and Subversion. Coming soon: Exuberant ctags.

Turns out there's no readlink(1) on a fresh Mac OS install, either. I don't know what to do about that. Most of my Java programs use that to cope with users running them via symbolic links.

New cinema displays' power button

On the old 23" cinema display, the power button would put the computer to sleep or wake it, depending on its current state. On the new 23" cinema display, the power button brings up a dialog asking "Are you sure you want to shut down your computer now?"

No, I'm sure I don't. I want to put it to sleep, like before. Having to click the "Sleep" button sucks ("Shut Down" is the default). I've looked in System Preferences, but the Options tab in the Displays item has the "Puts the system to sleep or wakes it" option selected. I don't want "Turns the display on and off" or "Does nothing". I want what I seem to have selected.

Only that's not what I get, and I don't understand why.

Finding Xcode

Turns out that the developer tools are hidden in /Applications/Installers/Xcode Tools. I did look for /Developer, which wasn't there. And then I tried "locate .mpkg", but the locate database hadn't been built.

So now I'm running /etc/weekly manually and wondering what the best solution for that problem is, given that cron(1) doesn't really take into account that my machine isn't always on.

Still can't find X11.

The new cooling system is impressive. On the whole, my dual G5 is quieter than my PowerBook. I was joking about it sounding like the air conditioning coming on: at its loudest it's not as loud as the dual G4, and it's only ever momentarily loud.


GarageBand but no Xcode?

So I lug all 28kg of new computer up the stairs; the first time I've been out of breath at the top of three flights of stairs! I unpack my first 64-bit computer. I set up my first water-cooled computer. I watch as it boots slower than my dual G4, and make a mental note to look into that later.

I "humph" as I drag Terminal to the dock, but think "fair enough; anyone who needs it knows where to find it".

And I stare in amazement when I find that cvs isn't installed.

Or make. Or g++. Or Xcode. Or X11.

Which is really lucky for me, because I only have 144GiB free. I'm not sure I could spare the room. Not a whole 1GiB.

hydrogen:~$ du -sh /Developer/
654M /Developer/
hydrogen:~$ du -sh Music/GarageBand\ Demo\ Songs/
359M Music/GarageBand Demo Songs/
hydrogen:~$ du -sh /Library/Application\ Support/GarageBand/
1.8G /Library/Application Support/GarageBand/

(Debian exhibits this kind of anachronistic parsimony with apt-get, too. Asking me if I really want to install a whole 2MiB of something I just asked it to install when I've got 100GiB free. Hey, computer: what did I just tell you to do?)

I've got javac, which is touching, but that's not enough.

There isn't even a Developer Tools CD, like you get with a copy of Mac OS off the shelf. So now I'm downloading XcodeTools1.5__CD.dmg and seething slightly. I expected my first night to be unproductive, but I expected to spend it with configuration nonsense rather than waiting for stuff to download.

But at least I have GarageBand, eh?

Keynote I might have used once or twice, but GarageBand? Are 15 year old kids really buying dual 2.5GHz G5 machines? (Even at 15 I'd have been hard pressed to think of a use for GarageBand.)

It's quiet, though. They've got that whole noise thing sorted. Until it gets busy. Then it sounds like the air-conditioning. And then it goes silent again while still working equally hard. That might taking some getting used to. It reminds me of the refrigerator, whose noise seems tied to some secret rhythm of its own. And which, on hearing mention of its name, has just come to life.

And the keyboard's better than the dual G4's. The clear plastic cover that dust and hair and cookie would set up home under: gone. Which looks pretty cool, and is definitely going to be easier to keep respectable-looking. (I wish I could have one without a numeric keypad. In all my many years of using computers, I've never found a use for the numeric keypad, unless you count obstructing the mouse or stealing space for my iPod's dock.)

Anyway, I have my tools now. Though I'm still missing X11, I can probably continue to live without it. If I really wanted X11, I'd be using Linux on amd64, wouldn't I?

At least we have a new world record amongst the computers I can log in to:

hydrogen:~/OpenSource/jikes elliotth$ time make -j2

real 1m19.911s
user 2m4.250s
sys 0m24.360s
hydrogen:~/OpenSource/jikes elliotth$

It's not quite twice as fast as my dual G4, but it's getting there.

Now all I need to do is remember all the things I've promised to do "when I get my new computer". And then do them.


Sweet November

For some reason, I thought Sweet November was the one with Winona Ryder and that old guy, but that turns out to be Autumn in New York, which I'm sure tbs will get round to before long.

How many more romantic comedies can there be?

But this was "Sweet November". And definitely San Francisco, and definitely Keanu Reeves. Plus Charlize Theron, who I always know I know, but always have to ask imdb before I recognize her. (In Monster, not only did she look nothing like the model/actress she is, she looked convincingly like the woman she played. You have to watch the documentary Aileen: Life and Death of a Serial Killer too.)

While finding the name of "Autumn in New York", I noticed that Keanu Reeves and Winona Ryder are both in next year's A Scanner Darkly. That's one of my favorite books, but somehow something always seems to go wrong with Dick adaptations.

Oh well. I just got a tracking number for my dual G5, so I'll have that, as promised, before November.



Cubes and stalls

Speaking of dumping core... they seem to have some funny ideas about privacy in the US.

I'd never understood all the talk of cubes on slashdot. Surely, I thought, that's only for call-center workers? Workers whose employers don't care about them, and aren't content with treating them as interchangeable work units — they need the workers to know how low is the esteem in which they're held.

And then you look around in San Jose and Santa Clara, and they're ubiquitous. Walk through the world's largest (and, granted, sunniest) industrial estate, and look in the windows, and all you see are these high-walled cells. Even really nice-looking buildings, such as Nvidia's, are furnished like this.

It's like Brazil without the dentistry.

So I can see now why slashdot has so many ads for knick-knacks to clutter cubicles with. I always thought it odd, because I saw the slashdot crowd as primarily male, and the collection of knick-knacks as primarily a female preoccupation. (Not that men don't have collecting instincts; they just seem to be more of the "complete the set" persuasion.)

Something I don't get, though, is why the natives seem happy with the situation. For the bunch of Brits I know, it was intolerably depressing. Within a day, the cube walls were partially dismantled, and we now have some kind of Mondrian take on open-plan. The natives, though, seem to like things the way they are. Where they have glass panels between cubes, they've covered them over with posters. Where there would be natural light, they've drawn the blinds. There's now a natural light gradient directly proportional to the Brit density.

So maybe, I wonder, they like their privacy?

And then I need to go [that's a euphemism, like the sign where I live that promises a fine for anyone "walking their dog" on the lawn], and I'm confused. I'm confused about many things, though I've had some explained.

For example: the reason there are urinals so low a dog could use them is, I'm told, because they have to be usable by people in wheelchairs. The only wheelchair user I know is female, so I can't ask whether she'd seriously consider using a urinal. (I could, of course, but her answer wouldn't be interesting in the directly pertinent sense.)

So at least I don't have to worry about the secret army of midgets that infests public restrooms.

The real wonder, though, are the toilet stalls.

The first thing you notice is that they don't go down to the ground. You can recognize the occupant of the end stall by their shoes, socks, and belt buckle. That's how high they start.

They don't go up very far, though. Certainly nowhere near the ceiling, and not even above the height of a tall man. During those parts of the operation where you stand, I can hold a face-to-face conversation with a coworker who happens to be using a urinal. I know this, because I've done it. You can't not talk, because it's too weird otherwise. Like being buried up to the neck, naked, next to one another. I call that weird.

The doors seem to have unnecessarily fiddly handles. Call me Mr Burns, but I don't like touching anything I don't have to. I know how many people don't wash their hands. I like things I can operate with a kick or an elbow nudge. Not a "handle" so small it has to be grasped between thumb and forefinger like a china teacup.

Most taps (faucets), strangely, seem to be sensibly designed for elbow use. Though observation suggests that most people either don't realize this, or don't care. Maybe they haven't watched enough hospital drama?

[Apologies, while I'm here, to whichever member of staff at Dave+Buster's had to climb over (or under) to unlock the stall I locked from outside, just to see if the lock was as stupidly designed as it appeared to be. It was, and I was left with a door only unlockable from the inside, locked from the outside.]

Not content with stall walls being too short (in both vertical directions), a lot of the doors don't fit either. There are gaps wide enough to see through, both on the lock side and the hinge side. (This is actually less common, and doesn't seem to apply to most restaurants. Prior observations do.)

I used to think the unisex toilets in "Ally McBeal" were a joke. I'm no longer quite so certain.

And now I'm left thinking of Midsummer Night's Dream, and the references to Calista Flockhart/Helena's personage, her tall personage, compared to Anna Friel/Hermia's minimus, of hindering knot-grass made. And whether either of them would be visible to talk to.

Will my idea of a person's height forever be tarnished by the question of whether their head would be above or below the stall wall?

If only I'd been brought up in ancient Britain, maybe I wouldn't care?

My kernel lies over the ocean

On Mac OS, your core dumps end up in /cores/ rather than process' current directory. So instead of the traditional "gdb ./a.out ./core", I have to ls -l /cores/ or use tab completion to find out what the newest core is (if process 123 dumps core, it's written to /cores/core.123; I've no idea what happens when you get duplicates).

Anyway, I've been wondering why the times were all given as if my time zone was UTC; does the kernel not know what time zone it's in? Then I realized it isn't UTC. It's UTC+01:00. Oh, so maybe I just haven't rebooted since moving to US/Pacific?

Turns out it's a lot simpler than that. I wasn't working locally: I was sshed in to a machine in GB. So that explains why I've been using vi all day... I was beginning to wonder if I was losing my sanity.

Ph34r the network transparency!

(Ignore the vi bit.)


Teaching the Children Well

Hans Muller (@author in JComponent, JLabel, JList, JScrollPane, JSpinner, JViewport) wrote a blog entry Teach the Children Well about how awkward it is to write and run your first Java program, compared to how BASIC was.

Good job the kid didn't want to use Jikes; until this weekend, you had to explicitly specify a bootclasspath. Ironic really, because Jikes' diagnostics are so much more readable for both beginner and expert, and make a real (and effective) effort to help you fix your problem, rather than just point out that there is one.

It's not that javac is serious competition for g++ in the appalling diagnostics stakes; it just isn't anything like as good as Jikes. Where Jikes is the helpful and pertinent assistant, javac is the strictly accurate but obscurantist professor. (Find your personality type by deciding which you prefer: "no such method" or "unresolved identifier"?)

As for g++, it's the barely comprehensible Glaswegian alcoholic, mumbling to itself in prolix fashion as it rolls about in the gutter. Pressed for an answer, all you'll get is "parse error, ye feckless gobshite ye!" before it vomits two hundred candidate operator<<s on your shoe.

Anyway, if you're running Jikes on some flavor of Unix, you should now be fixed. Apple users are fine, because we know where they keep their Java. Other Unix users will have to ensure $JAVA_HOME is set, and we'll collect the JAR files from $JAVA_HOME/jre/lib/.

So, if Hans has the sense to tell his son's friend to get a Mac, that's that. (And he can learn C++, Objective C, Python, and Ruby, too.)

There's another Jikes bug open and assigned to me that's fixed, but remains unclosed because as an aside in the bug comments, Chris Abbey suggested automatically appending .java if we look like we're being asked to compile something that doesn't end in .java.

Since all Java source files' names have to end in .java, this shouldn't cause trouble for anyone else. And it would have helped Hans' kid's friend. So I'm a little more convinced now that maybe it isn't such a bad idea.

I'm not convinced you aren't better off with a decent makefile, though. Start as you mean to go on. I had to learn make to build my C programs at that kid's age, and I'm still using make at twice that age.

Why shouldn't the kid have to learn about the command-line and the shell to learn to program? What happened to the people at university who resisted? Did they become good programmers? I submit that they did not. I further submit that I never knew a good programmer who didn't know and respect Unix, even if respect doesn't imply love.


Arbitrary associations

I seem to have learned, after roughly a month's exposure, the arbitrary association between US coins and their denominations. It no longer seems to matter that the 5 cent coin is larger than the 10 cent coin but smaller than the 25 cent coin. Or that the coins don't clearly show their numerical value. I'm not looking any more; I just know.

No progress with the notes, though. How am I supposed to cope when all denominations are the same size, shape, and color? What does the Americans With Disabilities Act 1990 have to say about this? (Answer: there's no explicit mention, judging by the absence of the words "denomination", "money", "currency", "notes", and "bill".)

One possibility that occurred to me today: maybe US wallets have lots of different compartments for notes, so you can keep them segregated? I've taken to keeping my $1 notes separate from all the rest. I wonder how that will work as a coping strategy?


Let's fix Swing first

This was supposed to be a post about JDIC on Mac OS. Somehow I never got past introductory remarks about what else needs fixing to make Java applications at home on the desktop before we start to worry about JDIC.

Get the LAFs pixel-perfect

It's usually pretty easy to recognize a Java application. Ever since the move to Swing from AWT, the majority of components have looked slightly wrong. Even Apple's LAF, though very strong in some areas (the buttons, checkboxes, scroll bars, split panes, and tabs all look very convincing) is weak in others (lists, menus, popped-up combo boxes, and tables are all wrong in both look and feel). Windows has similar problems, and GTK+ has worse problems (perhaps the worst of all, from my limited exposure to it).

I'm not interested in the AWT/Swing/SWT argument; I do have opinions on the right way to have done things, but that's not relevant to the situation we're in. From here, the most important thing is to fix the LAFs. That would be an easy thing for outsiders to contribute to if Sun and Apple would only let us. There are plenty of us who've come up with little improvements (poking UIManager, writing our own subclasses or renderers) who'd love to contribute them and see all applications improve.

At the moment, neither Sun nor Apple offer us the chance, and we suffer for years watching these things stay the same.

Note that this isn't an argument that Java should be open source. I have no particular opinion on that: all I care about is that Java continues to exist, and continues to improve. What I'd like is a quick-turnaround way for people to submit patches and stay up-to-date in this one particular area, because it seems that's where Sun and Apple most need help. (I don't understand why Apple isn't wall to wall with the kind of person who gets upset when a pixel's out of place, and would stay all evening to fix it, but maybe they're just too busy with other stuff.)

Some access to platform-specific component variants

Although I said I'd avoid the AWT/Swing/SWT argument, we have a problem fundamental to the philosophy underlying AWT and Swing: there's no support for platform-specific components, even when they're very similar to ones common to all platforms. As a Mac user, I'd like to have a JTextField that's more like NSSearchField, for example. (I've written the extra functionality; it's the appearance that's hard for me to duplicate without the JNI that Apple use to get their rendering right.)

Swing is unlikely to ever offer me such a choice. I'm not sure what the pragmatic answer is here, but it might be (to continue with the example of NSSearchField) for the LAF to support some property on JTextField that makes it look like an NSSearchField. But if Apple don't have the time to fix the mandatory parts of the LAF, as appears to be the case, I won't be holding my breath for such optional niceties. (I've had an Apple bug open requesting a way to ask for a sheet for years now.)

Spelling checking

Any decent application has spelling checking. On the Mac, all applications that use Cocoa text fields (or the AWT TextArea) can turn it on with one line of code. Swing applications? Don't ask.

[If you want spelling checking in your JTextComponents on Unix machines, I've written the code for you. Download the salma-hayek library used by SCM and take advantage of spelling checking with only one extra line of code in your application.]

On the one hand, I'd push for no more API than a method setSpellingCheckingAsYouType in JTextComponent, thinking that the more latitude we give implementors the better, because that's how we'll get to be most like the native system. But on the other I know that I've done a better job than Apple, for example: I'm editing this now in a Cocoa text component and "JTextComponent" and "setSpellingCheckingAsYouType" are both marked as errors. The Java spelling checking I wrote recognizes them as camel-cased words and checks the constituent words individually.

For the good of Java applications and their users everywhere, though, I'd settle for being no worse than a native application. (And, to be fair, there are notable examples of native applications that can't do this. Mac OS X stands out as being significantly better than anything else in this regard, but even there iCal doesn't think to enable this very useful functionality. Mozilla Thunderbird on Linux is the application that causes me the most grief personally through lack of check-as-you-type. Plus just about anything I've ever used on MS Windows. Either MS Office won't share its spelling checker, or no-one else knows how to use it.)

Basic functionality should be free

There's a more general point here about functionality an end-user should be able to take for granted, too. Why can't a Swing programmer say "the user should be able to search this JTextComponent/JTable"? A GTK+ programmer can. A Cocoa programmer can (although they had to wait until 10.3, amazingly). [Again, if you want this in your software, check out my salma-hayek library, which offers you one-line addition of find to any JTextComponent. Not as convenient as it just being there, but better than nothing.]

Why can't I give a JTextField (or Document) to a JList or JTable and have the latter automatically filtered based on what's been typed? Just like in the iTunes interface. [Again, if you want this in your software, check out my salma-hayek library. But if it's not in the JDK, it won't be in 9 out of 10 applications.]

Why can't a Swing programmer say "the user should be able to sort on this column"? Hell, why don't we have default column Comparators the same way we have default renderers? MS Windows 95's tables had this: just add function pointer for instant sorting. That's a decade-old version of a C library on a platform known for cruftiness we're talking about, and we're not competing. That's embarrassing.

There are so many little things that a user can reasonably expect of a quality application that Java isn't making easy enough. Yes, for any default implementation/UI supplied, someone will be able to think of something better, but you can always override the default. The point is, you should be able to get something for nothing.

Common usage should be easy: forms

Simple dialogs need to be a lot easier to write. By "simple" I mean more complicated than JOptionPane; something more like a preferences dialog. Again, if you want this in your software, check out my salma-hayek library. It's not hard to automatically do a pretty good job, and it's trivial to do a better job than most of the chimps let loose with JBuilder or other devices for churning out terrible code.

There's no reason for it to take much more code to fully implement a form in an application than it would to simply add the required fields to a Collection. People have been writing such systems for years, and it's about time a major toolkit offered it.

Even if, overnight, the visual GUI builders stopped churning out the worst code known to man, there are other reasons to favor something like this. [Note that since I wrote that, I've added proper support for status information in dialogs, and both the source and the resulting dialog look better for it.]

(As an aside, we need to do something about the poor quality of example code. The tutorial, the almanac, and the demos are all poor examples of best practices. They're fine as quickly knocked-together demos of the available functionality, but we have to realize that this code turns in to shipping applications. We can't go round encouraging people to write code that looks like it came out of JBuilder without facing the fact that it's going to make Java look bad.)

We need a new JTextComponent for multi-line editing

Swing offers two basic choices if you want a multi-line text component. There's JTextArea and there's JTextPane. The former has important deficiencies in terms of features, and the latter has terrible performance (both space and time).

Yes, you can write your own editor kit, but that's a huge effort, and pretty difficult too.

(If nothing else, the API should be made more regular between these two classes. JTextArea has a load of useful line-based functionality missing from JTextPane; if you subclass JTextPane you can just paste in the methods from JTextArea and they all work fine. I think there's a missing JMultiLineTextComponent somewhere. Or maybe the mistake's in Document, and the functionality should never have been in JTextArea. I haven't thought about it.)

Cocoa manages to have a text component, NSTextView, that takes a good stab at being all things to all men. So should Java. I want to be able to have colors in text without rendering and editing being sluggish and my application taking four times as long to read in a text file, and only being able to cope with much smaller documents. I want to be able to implement coloring that has good enough performance that I'm not so embarrassed I feel the need to take it back out. (There's no reason for JTextArea to insist on a single color, even if it does insist on a single font. The latter is often a perfectly acceptable restriction; the former much less so.)

High-performance coloring and easy-to-use hyperlinks are must-have features for serious text components in 2004. So is check-as-you-type spelling checking.

I can see that anyone who's used Xcode might argue that NSTextView isn't perfect either; there was some sluggishness there, and it's plausible that at least some of that was something to do with NSTextView. But I challenge to you do anything like as well using Swing, and I bet if you do, you'll have had to write significant chunks of code, including your own views.

This is too important to be left to individuals

It's easy to say "if you think these things are so important, do them". I have, at some time or another, done all of the things I mention here. With varying degrees of success, and varying degrees of availability to the general public (or, indeed, to me).

For Java to hold its ground, and for Java to gain new ground, we need these things to be available for everybody writing Java. Maybe the answer is something like CPAN or RubyGems, so a program can declare its dependency on some library, and the VM will go and download it. But I don't think so. I think this stuff needs to be addressed in the JDK.

And whatever else we do, let's not have another AWT to Swing transition. Let's fix one or other of the systems we have.


Jikes 1.22 released

Only a little later than JDK 5.0, there's a compatible Jikes. Release notes and download here.

Although Jikes 1.22 works with the new JDK's rt.jar, there's no support for the new language features (i.e. no -source 1.5). You'll have to wait for 1.23 for any of that. Or compile from CVS, to at least get the enhanced for statement.