Insights from the Xlib Programming Manual

If you think X is dead, you are wrong. Widget toolkits like GTK try to hide it, but in the end, X is still the thing that handles events and puts pixels to the screen. Sometimes we need to reach through the muck and program it. Bogdan Gheorghe, a committer in training, discovered this the other day in the official Xib Programming Manual (it's been there from day one, I knew it was there but had forgotten):


Virtual Focus Crossing and the detail Member

We will now embark on specifying the types of events sent to each window and the detail member in each event, depending on the relative position in the hierarchy of the origin window (old focus), destination window (new focus), and the pointer window (window containing pointer at time of focus change). Don't even try to figure this out unless you have to.

At least these guys are honest, but how about defining API that is simple enough that it doesn't need to come with a warning?

Steve

BYTE Magazine, January 1997: "Can Java Replace Windows?"

IBM Labs Ottawa is cleaning out the old OTI library (a long time ago, we used to be OTI). I found a BYTE Magazine from January 1997 with the cover story, "Can Java Replace Windows?". Interesting that it is now 10 years later. I'd forgotten just how much hype there was at the time.

Here are some titles of the articles inside:

"Today the Web, Tomorrow the World"
"Why Java Won't Repeat the Mistakes of Unix"
"The Bitter Taste of Java"
"Corel's New PDA and Java Suite"
"Java to Power Flying Car"

Ok, I made that last one up.

Steve

Useless dialog of the day

Carolyn Macleod, accessibility wizard, was starting up Eclipse M-whatever yesterday and got this:

How useless is that? What file changed? How do you answer this question? At least tell me the file name.

I'm seeing a trend in software these days: attack the user with dumb dialogs. If you must attack, at least tell me something useful, like "All your base are belong to us".

Steve

This blog has been accused of having no content

The software Gods and the global cache

How many times have you done this: Scrolled through the code, saw something totally bogus, fixed it, and then got a bug report from someone just discovering the bug you fixed. This has happened too many times to be mere coincidence and it's not just bug reports. Discuss how you might implement a feature, and someone will request it right out of the blue.

I believe there are software Gods who maintain a global cache of all project activity. When you think of something or touch the code, the cache gets updated and someone gets notified.

Steve

Refuctoring your code

Have you ever done this: Tried to refactor your code ... and failed.

Amongst the many masterpieces that sit at the bottom of the Eclipse stack, SWT is one of the gnarliest. Implemented in Java, it's coded to the metal. Many things are inlined. It's full of version checks, work arounds for operating system bugs and wild hacks that make everything go. It's backwards compatible to the day it first shipped, yet somehow embraces and exploits the latest operating systems features.

Don't be afraid. This is normal for a high performance, operating system level library that isn't waiting for the hardware to get faster.

Anyway, while attempting to refactor some of the more crufty code, I failed. The refactored code just wasn't any better so I ran away from the changes. It took strength to step back, evaluate the situation, weigh the pros and cons and decide to throw it away. Really, you are throwing out more than code. It's the investment in the new way of thinking, rather than the changes, that you have trouble parting with.

Code that is refactored into worse code: that's refuctoring!

Steve