OSX Screenshot Script

Let’s say you wanted to capture a few images for a fade effect, which means you need a sequence of rapid screenshots. Here’s a script I’ve been using:

i=0 ; while [ 1 ] ; do i=expr $i + 1 ; screencapture -C $i.png ; sleep 0.1; done

Hit ctrl-c to kill it, then view the sequence with gqview or something. Then use the very cool Flysketch to grab the same position each time. Caveat: The 0.1 millisecond interval is optimistic, the powerbook seems to handle only about 3 pics per second.

The camera sound effect helps a lot as you know precisely which instant got taken and also creates the requisite fashion shoot ambience.

Here’s a sequence with a fade effect (One-Second Spotlight) from Everybody’s favourite fade effect website.

Image Hosted by ImageShack.us
Image Hosted by ImageShack.us

Image Hosted by ImageShack.us

The alternative would be to record it as a screencast and pick out the frames. I was using Wink under Linux, but haven’t looked into OSX tools, any suggestions?

Take the Ajax Challenge: What Can’t Ajax Do?

Working (offline) on Richer Plugin, I’ve expanded the list of reasons you’d want to use a Richer Plugin, i.e. Flash, Java Applets, Standalone clients, Firefox extensions etc.

Here’s the list of things Ajax can’t do on it’s own – what else is there?

  • Browser morphing Adding buttons, toolbars, bookmarks, icons; changing browser behaviour.
  • Local file access Reading and writing files on the user’s hard drive.
  • Sound Playing music and sound effects.
  • Rich graphics Providing rich graphics, changing dynamically. (This is gradually changing with the introduction of SVG in some browsers, but it’s no match for desktop graphics.)
  • Keyboard shortcuts Providing a full range of keyboard shortcuts while avoiding conflicts with the browser’s own keyboard shortcuts.
  • Hardware access Input from devices such as microphones, webcams, and gamepads; output to devices like printers and portable gadgets.
  • Extended communication Communication from the client machine to locations beyond just the base server, and in protcols other than plain old HTTP.
  • Operating system interaction Catching events such as shutdown initiation; changing preferences; popping up alerts; reading hardware information.

Take the Ajax Challenge: What Can’t Ajax Do?

Working (offline) on Richer Plugin, I’ve expanded the list of reasons you’d want to use a Richer Plugin, i.e. Flash, Java Applets, Standalone clients, Firefox extensions etc.

Here’s the list of things Ajax can’t do on it’s own – what else is there?

  • Browser morphing Adding buttons, toolbars, bookmarks, icons; changing browser behaviour.
  • Local file access Reading and writing files on the user’s hard drive.
  • Sound Playing music and sound effects.
  • Rich graphics Providing rich graphics, changing dynamically. (This is gradually changing with the introduction of SVG in some browsers, but it’s no match for desktop graphics.)
  • Keyboard shortcuts Providing a full range of keyboard shortcuts while avoiding conflicts with the browser’s own keyboard shortcuts.
  • Hardware access Input from devices such as microphones, webcams, and gamepads; output to devices like printers and portable gadgets.
  • Extended communication Communication from the client machine to locations beyond just the base server, and in protcols other than plain old HTTP.
  • Operating system interaction Catching events such as shutdown initiation; changing preferences; popping up alerts; reading hardware information.

You can get Ajax on the Internet???

Surgery by Ajax is imminent. We just need to solve that NP-hard URL problem …

CEO of Ajax The Slasher, David Hassaminor Hickup, said “We knew from the outset that AJAX would cure cancer. This is just the first step. Tomorrow’s children will be concieved via AJAX technology. We are working on an AJAX-enabled satellite with which we hope to probe the deepest corners of the galaxy, in search of the meaning of life. AJAX is bound to have a part to play in that quest. Our main task for now is getting the ‘back button’ to work during surgery. It seems intuitively obvious that pressing the back button will cause the last stroke of the scalpel to be undone. In practice, it’s a little harder than that.”

You can get Ajax on the Internet???

Surgery by Ajax is imminent. We just need to solve that NP-hard URL problem …

CEO of Ajax The Slasher, David Hassaminor Hickup, said “We knew from the outset that AJAX would cure cancer. This is just the first step. Tomorrow’s children will be concieved via AJAX technology. We are working on an AJAX-enabled satellite with which we hope to probe the deepest corners of the galaxy, in search of the meaning of life. AJAX is bound to have a part to play in that quest. Our main task for now is getting the ‘back button’ to work during surgery. It seems intuitively obvious that pressing the back button will cause the last stroke of the scalpel to be undone. In practice, it’s a little harder than that.”

Wikipedia as a Honeypot

How long until wikipedia becomes a honeypot?

“Who wants to be a millionaire” contestant is struggling to answer the question, “What year did the Fonz jump the shark?”, and calls out to Lifeline Buddy. Back in 2005, Lifeline Buddy would have googled for the answer. But this is 2007, and “wiki” is now a household name (the media refers to “wiki” and “wikipedia” interchangeably). Lifeline Buddy bangs out “fonz jump shark” into wikipedia’s search field and quickly finds the right page, reporting confidently the year was 1975. Only, it’s wrong; Fonzarelli, of course, jumped the shark in 1977. The producers had entered the fraudulent details at precisely the moment the lifeline was consulted. Contestant takes his $1000 consellation and exits, muttering something about the Britannica under his breath.

Producers wouldn’t stoop so low? If the BBC can do it, draw your own conclusion. The Register, in any event, would have a field day with their latest whipping boy.

Instead of restorting to restricting edits, wikipedia first needs to try out a “heat map” view to help people decide how stable the information is. Not as gaudy as the Ajax Patterns authoring heatmap (using a more subtle theme now), but some way for people to know what’s new and what’s old. Again, this comes back to the idea of separating out wiki content from presentation, ideally using some kind of web service. A wiki needs more than one view, even without any Maps/Flickr/Delicious mashup. For example, you could have three standard views:

  • Pure wiki reading, just like wikipedia today.
  • Stability view. e.g. Most content in white as now, but with a few shades of grey to distinguish how old each phrase is (darker grey = past minute, medium grey = past hour, light grey = past day; so a phrase “graduates” from grey to white as it matures).
  • Inspection mode. Full-on data mining interface, using Ajax (of course) to explore history, drill down to author info, etc.

Wikipedia as a Honeypot

How long until wikipedia becomes a honeypot?

“Who wants to be a millionaire” contestant is struggling to answer the question, “What year did the Fonz jump the shark?”, and calls out to Lifeline Buddy. Back in 2005, Lifeline Buddy would have googled for the answer. But this is 2007, and “wiki” is now a household name (the media refers to “wiki” and “wikipedia” interchangeably). Lifeline Buddy bangs out “fonz jump shark” into wikipedia’s search field and quickly finds the right page, reporting confidently the year was 1975. Only, it’s wrong; Fonzarelli, of course, jumped the shark in 1977. The producers had entered the fraudulent details at precisely the moment the lifeline was consulted. Contestant takes his $1000 consellation and exits, muttering something about the Britannica under his breath.

Producers wouldn’t stoop so low? If the BBC can do it, draw your own conclusion. The Register, in any event, would have a field day with their latest whipping boy.

Instead of restorting to restricting edits, wikipedia first needs to try out a “heat map” view to help people decide how stable the information is. Not as gaudy as the Ajax Patterns authoring heatmap (using a more subtle theme now), but some way for people to know what’s new and what’s old. Again, this comes back to the idea of separating out wiki content from presentation, ideally using some kind of web service. A wiki needs more than one view, even without any Maps/Flickr/Delicious mashup. For example, you could have three standard views:

  • Pure wiki reading, just like wikipedia today.
  • Stability view. e.g. Most content in white as now, but with a few shades of grey to distinguish how old each phrase is (darker grey = past minute, medium grey = past hour, light grey = past day; so a phrase “graduates” from grey to white as it matures).
  • Inspection mode. Full-on data mining interface, using Ajax (of course) to explore history, drill down to author info, etc.