Posts Tagged ‘leopard’

Apple’s Mac OS X version 10.5.

blur for iTerm

Thursday, July 3rd, 2008
iTerm+blur screenshot

iTerm+blur screenshot

I’ve been a fan of terminal transparency since there have been terminal-emulators that supported it (although in the old days, it was just showing the X11 root window with some tinting). I’m not alone, and similar terminal-emulator users have been ahead of their time with respect to the transparency-fetish that is now popular.

Back on Windows 2k and xp there were various hacks that could turn a window transparent (I used one that came with my nVidia drivers). They weren’t perfect, as the transparency included the window borders and chrome, but they granted real transparency: where the background is a composition of alpha-blended windows. This added a little bit of depth to the desktop, rather than just having pretty terminal backgrounds.

When I moved to OS X, iTerm did it properly (i.e. without making the UI parts transparent). However, at the end of a long night hacking, with several accumulated editor and terminal windows full of text merged on top of each other, there is a serious readability problem with low opacities.

I use transparency because:

  1. It’s easier on the eyes than high-contrast text-on-black.
  2. It’s multiplexing content from multiple windows without consuming screen resolution. This is a fidelity trade-off: as the visibility of lower layers of text increases, the accuity of the frontmost (focused) layer decreases.
  3. It impresses others.

When I saw Vista’s glass effect, the first thing I thought was “finally the answer to stacking translucent terminals!”. Combining blurring with transparency preserves the accuity of the focused window while transmitting enough information to be useful. So you won’t be able to transcribe text from below, but you can see if there’s, say, a burst of activity in IRC.

I suspect Microsoft got some IP rights on it, because Leopard has the most subtle application of transparency+blurring ever (in sheets and the menu bar), compared to Aero’s egregious UI-glassing. However, the imporant thing is that the new Core Image filters can be applied to windows, with a compositing mode that is perfect for terminals (and text editors for that matter).

One stumbling block is that the API to apply window filters is undocumented. Fortunately, thanks to the CGSInternal headers some of this API has been exposed.

It’s already been exploited for Apple’s, but that requires Input Manager patching hacks. I gave reasons why I prefer iTerm in my last post, but here’s another one: it’s open source and so I can add blurring in myself.

Update: check out the source at github, or the built binary.

Update: The patch has been merged into upstream CVS. Yay!

Leopard ahoy!

Tuesday, July 1st, 2008

Now that fink has finally started to show some maturing support for Mac OS X 10.5, I’ve upgraded on scud.

I re-used my home directory from Tiger, without any help of migration tools other than chown. upgraded its data and so far everything’s gone smoothly.

Managing users has changed a bit: you have to Ctrl+click the account in System Preferences and select “Advanced Options” to change the usual POSIX fields. If you’re serious, check out dscl(1):

 dscl . -read /Users/$(whoami)

Looks like Apple’s has improved a great deal, almost surpassing iTerm. However, it still fails short in the tab apartment: AFAICS’s tab titles always display the process name and don’t respond to the usual xterm escape codes, and the visual style of the tabbar isn’t nearly as nice as iTerm’s Aqua style.

Trying to switch to fink unstable doesn’t work as advertised: you must use the CVS method of selfupdate (rsync being the default).

After Software Updating to 10.5.4, broke.

1/07/08 4:04:01 PM org.x.X11[12697] /usr/X11/libexec/x11-exec: Unable to find application for org.x.X11

Since Apple’s official updates are lagging by more than 6 months, it’s better just to get it from the xquartz project.

Photoshop doesn’t like case-sensitive filesystems, but there is a (tedious) workaround. I totally agree that this is just laziness on the part of the Adobe devs: it would take 1 man less than a day to do the appropriate case consistency changes given the source code: there’s nothing to break.