#!/bin/sh

curl -o /tmp/webkit.dmg http://nightly.webkit.org/builds/Latest-WebKit-CVS.dmg

hdiutil mount /tmp/webkit.dmg

if [ -d /Volumes/WebKit/WebKit.app ]; then 
    rm -rf /Applications/WebKit.app
    cp -pR /Volumes/WebKit/WebKit.app /Applications/
fi

hdiutil detach /Volumes/WebKit

Sure, it could be a little more robust (or you might prefer one of the other two builds), but it works. Put this in a new file, chmod +x it, and drop it into /etc/daily to have it run each morning.

(updated 2005-12-21 to reflect new webkit packaging and fix minor bugs)

[Update: I discovered my previous solution didn’t persist between restarts of Quicksilver, so here is a working solution] It’s pretty simple…

• First make sure you have the “Extra Scripts” plugin installed
• open your Quicksilver Preferences and go to your catalog.
• Add a new “File & Folder Scanner” and point it to ~/Library/Application Support/Quicksilver/PlugIns/Extra Scripts.qsplugin/Contents/Resources/ExtraScripts
• Set “Include Contents: Folder Contents” and “Depth: infinite”

I originally used MenuTunes, and most recently Synergy to provide global “hotkeys” to do some simple things like play/pause iTunes, skip to next or previous track, and display some information about the current track. Quicksilver’s triggers are ideal for this — it allows you to create keyboard shortcuts to perform any Quicksilver action. This let me setup keys for play/pause and next/previous track.

Additionally I setup the iTunes Quicksilver plugin to display track notifications and to send those notifications to Growl, however the plugin only displays notifications when something happens like the track changes. I want to be able to display track info at any time so I whipped up this simple Applescript, saved it to my scripts folder, and assigned it to a Quicksilver trigger. This will display the exact same as the built-in iTunes notification in Quicksilver with the addition of track time, current position, and ratings stars. It’s a very simple matter of displaying more or less info for the track.

[updated 09 Aug 2005 to work when no artwork is present]

tell application "iTunes"
  set currentTrack to current track
  set theArtworks to artworks of currentTrack

  if ((count of theArtworks) > 0) then
    set theArtworkData to data of item 1 of theArtworks
  else
    set theArtworkData to null
  end if

  set theArtist to artist of currentTrack
  set theAlbum to album of currentTrack
  set theTime to time of currentTrack

  -- set the rating stars
  set theStars to ""
  set theRating to rating of currentTrack
  set bStar to «data utxt2605» as Unicode text
  set wStar to «data utxt2606» as Unicode text
  repeat 5 times
    if (theRating > 0) then
      set theStars to theStars & bStar
      set theRating to (theRating - 20)
    else
      set theStars to theStars & wStar
    end if
  end repeat

  -- get player position and format to MM:SS
  set positionMinutes to (player position div 60)
  if (positionMinutes < 10) then ¬
    set positionMinutes to "0" & positionMinutes
  set positionSeconds to (player position mod 60)
  if (positionSeconds < 10) then ¬
    set positionSeconds to "0" & positionSeconds
  set thePosition to positionMinutes & ":" & positionSeconds
end tell

tell application "GrowlHelperApp"
  if (theArtworkData is not null) then
    notify with name ¬
      "iTunes Notification" title ¬
      name of currentTrack description ¬
      theArtist & return & theAlbum & return & thePosition ¬
        & " / " & theTime & "     " & theStars application name ¬
      "Quicksilver" pictImage theArtworkData
  else
    notify with name ¬
      "iTunes Notification" title ¬
      name of currentTrack description ¬
      theArtist & return & theAlbum & return & thePosition ¬
      & " / " & theTime & "     " & theStars application name ¬
      "Quicksilver" icon of application "iTunes"
  end if
end tell

Windows provides access to all program windows via the window handles. Think in terms of each program has a window number. That program has invisible sub-windows that each has a number. I parse all the window handles every few seconds and grab the URL in the address bar where the window is id’d as a browser. — email from lead x3watch developer

I’ve run across a couple of posts on the x3church forums where people are using browsers that aren’t supported (at the time of the above email, Firefox was the only “major” browser known not to work). The problem is that the above approach relies on a specific API of a specifc operating system, as well as the browser identifying itself properly. And what about when you don’t have any browsers open, or aren’t actively surfing the web? x3watch is still processing every window you have open every few seconds — very inefficient. Additionally, x3watch only grabs the URL from the browser and must download the page again in order to parse it for keywords.

The solution I created for the Mac version relies on packet sniffing. Essentially, a process is run in the background that listens for all incoming web traffic. The contents of the packets can then be analyzed on the fly and logged. I believe this to be a much better solution, as it

• is OS and application independent — packet analysis exists on all platforms. This is the biggest one to me, since the same core engine can be shared across every version of x3watch.
• does not require the page to be downloaded more than once
• could easily be expanded to include other transfer methods such as FTP (though this would use more domain matching, and not as much content analysis)

Another Longhorn feature talked about was the enhancements to WinFS and Explorer (was called “Windows Explorer”, but I think it may be called “Document Explorer” now). WinFS was originally supposed to be a database powered file system, providing rich metadata and search capabilities. That idea has long since been scratched off the Longhorn road map, but they are still working on an extensive document metadata index. As it turns out, this should be very similar to Spotlight. Longhorn will also have “virtual directories”, akin to “smart folders” in Tiger. Blow for blow, it seems Microsoft and Apple have very similar plans for changing [for the better] how people will interact with their files. I say this not accuse one company of copying the other; on the contrary, I see this paridigm as a rather natural progression based on current trends in the search industry. What really gets me though, is the timeline — Tiger debuts in two days, while the most recently announced debut goal for Longhorn is “Holiday 2006” (given Microsoft’s track record, this can be read as “mid to late 2007 at the earliest”). We’re talking about a 2 year difference here… that is several lifetimes in this industry; I can’t possibly imagine what Apple will be rolling out two years from now.

So Apple just announced today that Tiger would ship on April 29, and I’m just giddy like a little school girl… it’s quite ridiculous really. I’ve been looking at all the new features that are to be included and was really impressed by the new stuff in Address Book. Because of some recent stuff we’ve been doing at Visible, I had this great vision of how things could (and should) work.

Visible School is holding a large fundraiser later this month and Rick has been working on sending out personlized invitations to a rather large group of people. He’s been keeping track of everyone’s information in an Excel spreadsheet and is then doing a mail merge in Word to create the letters and all. He could have done the same for envelope labels, but they opted to just hand-write them (not sure why). Anyway, the problem is that the only copy the school has of these people’s contact info is in the spreadsheet on Rick’s computer. These could be potential future donors so it would be nice to have them in a more permanent spot, so imagine this scenario —

All of these guests are entered into Visible’s master LDAP directory… they could be in their own branch if need be, but it would likely suffice to simply put them in the main users branch with an eduPersonAffiliation of “donor” or something. Some of the contact information for some of these people may be private so we would set permission levels accordingly (and because Address Book allows you to authenticate to LDAP it would all be transparent to the end user). Rick could then just open Address Book and search for “donor” (some customization would need to be done so that the eduPersonAffiliation field would show up), then use the new label printing feature that will be added in Tiger to print out labels. I would imagine he could also export them in a format to be used for a mail merge to do the covers letters.

So how is this different than just using a spreadsheet? Well, on the front-end it wouldn’t be much different… probably about the same amount of work (if not a tad bit more). However, all of these donor’s information would now be stored where they belong… in Visible School’s master contact database. As we get more donors they are simply added as well, and when the next fundraiser comes along, Rick simply searches for “donor” again. It doesn’t seem all that revolutionary, but if you could see the way things are done now you’d understand how great this would be.