tewha.net

For years, Find has marked its matches by highlighting the text it finds. This was great in 1980 with black and white screens, where highlighting meant inverting. It was even decent in 1990, where multi-color text on a white background was the norm, and the highlighting meant changing the background color. But in today’s era of ransom note-like text, where it’s quite possible that the web page’s background consists of many background colors (including, quite possibly, the highlight color) it just isn’t enough to grab the eye.

Back in the 1990s, Apple had a solution to this for their help system.

That would be a great model for Find. However, we can do even better. Seen how System Preferences on Tiger works yet?

So here’s how Find should work (screenshot produced by blending a “normal” screenshot from OmniWeb with one manipulated with OmniDazzle). It’s pretty clear what was found, isn’t it?

Now, I’m not meaning to pick on OmniWeb in particular. Safari should do this. Text Wrangler should do this. Xcode should do this. For that matter, every application with a Find command should probably do this. We’ve had the technology for years. It’s time to use it to make life easier for users. C’mon Apple. Make this easy for us.

“If it’s smart it will call the iPhone a ‘reference design’ and pass it to some suckers to build with someone else’s marketing budget. Then it can wash its hands of any marketplace failures. It should do that immediately before it’s too late… Otherwise I’d advise you to cover your eyes. You’re not going to like what you’ll see.”

We develop applications for multiple platforms here. How to do this is something of a challenge; in the past, I’ve favored writing custom interfaces and using common business logic. To be blunt, I still think this makes a lot of sense, although in the past we’ve made some choices as to the various languages to write things in that turned out pretty poorly over the years.

Another developer here suggested we evaluate Qt. To make a long story short, we’ve placed an order and plan to use it.

Project configuration made easy.

Qt’s cross platform abstraction starts with the project file. For instance, a trivial QT project file might look like this:

TEMPLATE = app
SOURCES += main.cpp

Type qmake on the Mac and it’s converted to a Project Builder or Xcode project. I believe makefiles are supported on Mac, too, but I haven’t tried that yet. Import it into Visual Studio with Qt’s Visual Studio integration and it becomes a vcproj.

Want to add precompiled headers and make it a debug build?

CONFIG +=debug
PRECOMPILED_HEADER = stable.h

(This assumes that stable.h #includes your headers that aren’t going to change.)

Run qmake again on the host platform (or import into Visual Studio), and the project file will be regenerated to use stable.h as a precompiled header and we’re using debug libraries and appropriate settings.

Want a universal build on the Mac?

QMAKE_MAC_SDK = /Developer/SDKs/MacOSX10.4u.sdk
CONFIG +=x86 ppc

Want to build a Visual Studio project? Move over to Visual Studio 2005 and choose Open Solution from .pro File. A second later, you’re looking at a Visual Studio project with the equivalent configuration.

It really is that easy. The difficulty is in finding the variable names, and that’s documented on TrollTech’s website.

A new utility for keeping your Mac OS X applications up-to-date. An increasing number of applications do this themselves, but it’s nice to have a centralized system for it, especially in an era where increased security awareness is needed.

Today’s Worse Than Failure gripes about a dialog that doesn’t seem to exist in Mac OS X 10.4.9, and mostly seems to use it as a launching point for whining about Apple’s ad campaigns.

Here’s the dialog they claim:

The reason this dialog is worthy of mocking is because it only presents a single option. Har har har, funny, right?

But here’s what I actually got when trying to recreate the issue:

How’d they get that result? I have no idea. Perhaps it was present in an older version of Mac OS X, or perhaps there are some hacks interfering with Finder’s presentation of the dialog. Some repro steps would be nice.

I’ve been frustrated lately by slow build times on my mini. I found out why a few days ago, and have been from time to time adding a few notes to a draft article. The time has come to declare the article done…

An Xcode build on my personal PowerBook (it has 768MB of RAM), with a bunch of applications open:
VM: 5.81G + 150M 220631(1) pageins, 60523(0) pageouts

The highest number I saw there was about 200, and it appeared only once or twice. The vast majority of the build, it was 0.

An Xcode build on the Intel Mac Mini (it has 512MB of RAM), with only Finder and Xcode running:
VM: 8.93G + 7.19M 760989(93) pageins, 277742(22) pageouts

The highest number I saw was 3,180. Usually, it hovered around 100-200, with occasional drops to 0 depending on the phase the build was in.

There’s a couple obvious points here:

• The mini is doing at least one order of magnitude more swapping than the PowerBook. The total pageins don’t reflect that the PowerBook has seen much heavier use since the last restart, but that’s irrelevant to the recent pageins. More pageins is to expected; after all, the mini has less memory.
• The mini is using much more VM to accomplish less than the PowerBook. This I didn’t expect. The PowerBook is running more applications and is even using a FileVault-encrypted home directory. The mini, on the other hand, is as bare as I could get it without wasting time on it.

Slashdot warns us not to google “How to murder” before killing someone. Of course, just not killing someone is a much better choice.

Sure, Mac OS X is more secure by default, but what’s left open? Part one and part two.

Gene-modified corn MON 863 is considered dangerous after research results in rats show signs of toxicity.

Scientists who questioned mankind’s impact on climate change have received death threats and claim to have been shunned by the scientific community.