Idle Time

If you know someone who’s recently taken up programming the Mac or the iPhone (or both), please give them one (or both) of these links:

• For new Mac programmers
• For new iPhone programmers

As a frequent answerer of questions on Stack Overflow, I see certain patterns—not just frequently-asked questions, but also frequently-unasked questions: Things that are biting the questioner that they don’t know about.

Sometimes they’re thinking about things the wrong way (e.g., using property list objects where they should have a model). Sometimes there is a route to a solution (“my app is slow” “run Instruments”), but they don’t know about that route. Often, they’ll use wrong terms that are right on another platform (like “member variable”), like a speaker using their native language’s pronunciation rules when speaking a foreign one.

To help people over these speed bumps, I’ve composed an introduction for new Cocoa and Cocoa Touch programmers. (Both of the above links redirect to it.)

If any part of it doesn’t help them (i.e., is unclear or wrong), I’d appreciate it if you’d let me know, either here or by email.

Today’s Ship-It Saturday is a command-line interface to the Finder.

The two most useful commands are:

• finder reveal file, which will select the file in a Finder window, and
• finder update (or updated) file, which will tell the Finder that the file has been updated.

The latter command probably is not too useful anymore, but the command-line tool should work on no less than 10.4, and could probably be recompiled for even older versions of Mac OS X, so you may still have a use for it.

The third video of last month’s meeting is now up. Here are three easy-to-remember links:

1. http://bit.ly/CHLF2009Leaks1
2. http://bit.ly/CHLF2009Leaks2
3. http://bit.ly/CHLF2009WebInsp

You’ll notice that the third video is not CHLF2009Leaks3.

Unlike the other two, this one features Scott Ellsworth, our organizer, demonstrating the Web Inspector in WebKit. He starts off in Safari, then switches over to Chrome. He also talks about a profiling tool that’s part of Google Web Toolkit called Speed Tracer, although he wasn’t able to finish a demo of it in time for the meeting, so he talks about one of the examples instead.

I don’t think I’ll link these here anymore. If you want to find out about future CocoaHeads Lake Forest videos, subscribe to the CocoaHeads Lake Forest channel on Vimeo.

This is an expansion of a reply I wrote to a tweet by Daniel Jalkut. He wrote:

Imagine if the iPhone home screen showed a matrix of “generic” icons before filling in real ones. Mac Finder is a disgrace.

He’s referring to behavior introduced in Snow Leopard: When you visit a folder for the first time in a session, the Finder shows every symbolic link and alias with the kUnknownFSObject icon (  ), every application with the generic application icon, every file with the generic document icon, and every folder with the generic folder icon, before displaying the item’s real icon and then its Quick Look thumbnail.

Compare the environment of SpringBoard (on a non-jailbroken device) to that of Finder:

Compare also how SpringBoard and Finder obtain icons*:

SpringBoard hasn’t much to do, it’s in a straightforward environment, and the task and environment provide a couple of obvious caching strategies. The iPhone doesn’t have as much processing power, but what it has is enough—it can just get and display the icon without being lazy about it.

In fact, SpringBoard probably doesn’t even need to be asynchronous about it; all it needs to do is keep three pages of icons (current, next, and previous) in short-term memory. When the user flips one page, drop the farthest page out of the short-term memory cache and load the next one into it.

Meanwhile, on the Mac, getting an icon is not straightforward, and the environment can throw a monkey wrench into the works at any point. Every icon can take dozens, hundreds, or thousands of milliseconds to display, and more icons mean more opportunities for a stall. The solution is to load and show the icons asynchronously and in parallel—but then, what to show in the meantime?

Thus, for the Finder, lazy loading makes sense. The Finder can show you what it has (filenames and other basic metadata) immediately. You can work with those files, scroll to other files, or move through the folder hierarchy without having to wait for icons. And while you do that, the Finder has all the time it needs to asynchronously fetch the icons and, if it’s still appropriate, display them.

It’s a feature, not a bug.

There’s a recurring myth going around, which goes something like this:

In fact, using Carbon locks you out of 64 bit.

No, it doesn’t.

The truth is that some APIs that are part of the Carbon sub-frameworks are not available in 64-bit. Merely linking against Carbon does not mean your app suddenly stops working in the 64-bit world.

Carbon itself is just an umbrella framework. It doesn’t have any APIs that it provides immediately; everything comes from either another framework or one of its sub-frameworks.

Examples of the first category include Core Foundation, Core Services (home of Launch Services), and Application Services (home of Core Graphics). Even these are not immune to the myth, as demonstrated by the comment I linked to above: It’s on an answer suggesting a Core Foundation function. The answerer referred to it as a “Carbon function” (true in a sense), and the commenter pounced.

Many things that were once explicitly considered part of Carbon, such as the File Manager and Resource Manager, are now part of Core Services. Note that they haven’t even been consigned to the Legacy Library!

In the other category, even some APIs that remain strongly identified with Carbon, by being in a direct sub-framework of Carbon, are still at least partially around. One of these is the Carbon Event Manager, which even has the word Carbon in its name. Try registering a hot-key with it in a 64-bit-only app—it’ll work. (That one is in the Legacy Library. I should probably file a bug on that.)

What is deprecated and not available in 64-bit, as you can see in the Carbon Event Manager Reference, is anything that you would need to build your application on Carbon. That’s what’s deprecated: the concept of a Carbon application. Only Cocoa apps remain.

But some parts of “Carbon” are useful for things other than building a Carbon application. You can use them from a Cocoa application, or from a command-line tool.

Those APIs are still around. They are not deprecated, they are still useful, and they are still available in 64-bit. Use them freely.

(Oh, and before anybody mentions it: No, those NSEvent class methods introduced in Snow Leopard are not direct replacements for Carbon Event Manager hot-keys. You’d have to sift through the events yourself, whereas Carbon Event Manager filters them for you and only calls your function when your key is pressed. The correct analogue would be CGEventTap.)

Some of you know that I use a second-generation iPod nano (the best iPod ever) with an iPod Radio Remote. There are two generations of iPod Remote; here they are side by side:

The original is on the left. It was for the 2G iPod (that’s what I had, anyway) and possibly some other models. That remote didn’t have a radio tuner in it. The one on the right, the one that has a Dock connector and looks like a 2G iPod shuffle, is the iPod Radio Remote.

The iPod Radio Remote never did work with the iPhone and iPod touch. Every introduction of a new iPhone or iPod touch model (including the originals) made clearer that they’d either make a third generation or kill it. Sometime around the time when they introduced the new Apple Remote, they chose the latter.

At some point, Griffin Technology introduced their Navigate. I spotted one today at Walmart for $20 on clearance and snapped it up. Walmart normally sells it for $50, and MSRP is $60.

Not only does the Navigate work with my 1G iPod touch, it adds a display showing the current track. The iPod Radio Remote never had this! The picture on Griffin’s website doesn’t do it justice; it actually looks much better, as shown in this video:

(If you want to really see how good it looks, click through to the YouTube page and watch it there.)

Like the Radio Remote, the Navigate has a clip. Unlike the Radio Remote, it’s not a moving part; it’s just a fixed, flexible (but not too flexible, but not too stiff, either) bit of plastic. Time will tell how easy it is to break.

True to its name, you can even use it to navigate your music: It will let you pick a playlist, artist, or album to listen to, and change the shuffle setting. However, it does not let you go straight to a specific song, which makes that feature useless for me. I understand why that limitation exists, though: It would be much more difficult to scroll to it with the Navigate’s buttons than with the iPod’s own click wheel or touch screen.

Navigating the FM band isn’t exactly easy. When moving along the frequency band itself, next and previous move one frequency-stop at a time. You can set presets, but only four of them. It’s not at all obvious how to set and use them; I’ll leave it to the manual to explain it. Ameliorating this problem is that it remembers the last station you had tuned, so it’s not like you’re going to have to deal with the preset menu every time you turn on the radio.

I do have a couple of significant problems with it.

The first is that it doesn’t remember your volume setting. (The Navigate has its own volume setting, separate from the iPod’s; the iPod’s volume setting has no effect on audio through the Navigate. This is another difference from the Radio Remote, which had no volume of its own.) The Navigate doesn’t have a battery; it relies on the iPod for power, so it goes dead when you unplug it. Then, when you plug it back in or plug it into a different iPod, it’s back to the default volume, which is quite loud for me. This will probably grate on me a bit.

The other problem is that it doesn’t fit in my iPod touch’s Dock connector with its SeeThru hard case on it. My iPod nano doesn’t have a case on it, so I don’t have that problem with that iPod. If you don’t have a case on your iPhone or iPod touch (or other iPod), or you use a different case that won’t conflict with Griffin’s Dock connector, then this won’t be a problem for you.

I hope a future version of the Navigate will remember the volume setting and have a slightly thinner Dock connector so that it isn’t blocked by my iPod touch’s case. Even now, though, I consider the Navigate a worthy successor to the iPod Radio Remote, primarily because of the display, secondarily because of the iPod touch (and iPhone) compatibility.

This is a little one, inspired by a Growl discussion list thread. Enter the bundle identifier or name of an application, and Application Locator will reveal it in the Finder.

At the end of March of last year, I predicted that I would download more than 11,000 free songs in that year.

The final tallies are in.

I downloaded and added 11,466 free songs within 2009. At the stroke of midnight, I was still catching up on my backlog of Chromewaves; once I’d finished, I had a total of 11,554 free songs that had been published in 2009.

Either way, I met my prediction: I downloaded and added more than 11,000 songs, approximately doubling-and-a-half my library from its size at the start of 2009, for free. (I did buy some music as well, easing my conscience.)

I’ve refined my stable of sources over the past year. Here’s my current list of subscriptions:

• Chromewaves
• eMusic Daily Download
• Largehearted Boy
• McGuinn’s Folk Den
• Mercedes-Benz Mixed Tape (best viewed with JavaScript turned off)
• MPR The Current Song of the Day
• New Weird Australia releases (added 2010-01-16)
• NME Daily Download
• Spinner MP3 of the Day
• triple j

Naturally, I also download all of the free songs on iTunes and free songs on Amazon every Tuesday.

For those of you who’d like to follow these sources in your feed reader:

UPDATE 2010-01-16: Added New Weird Australia to the list.

Make RAM Disk still works, which is not surprising, considering it’s based on a few built-in commands.

What’s changed is that the disk images system is now 64-bit, so if you have a 64-bit-capable Mac, you can create a single RAM disk bigger than 2 GiB—you no longer need to make multiple RAM disks and RAID them.

John C. Welch has written an article telling you to use UTIs to replace creator codes.

It is wrong.

Daring Fireball, rosscarter.com, and (the most sober of the bunch), TidBITS have all gotten on the “Apple has abandoned creator codes, now we’re screwed, damn you Apple” bandwagon. They’re all right about one thing: Apple has dumped creator codes in Snow.

So before you panic, there’s a replacement mechanism, the UTI, or Universal Type Identifier.

No. Uniform Type Identifiers are a replacement for type codes (and MIME media types, and filename extensions), not for creator codes. There is no replacement for creator codes.

Uniform Type Identifiers are just that: They identify types of data. Using them for anything else is misusing them.

Ideally, Coda should assign an application-specific UTI for CSS files it creates.

No, it should not.

As it turns out, Coda is a UTI-aware application, and according to Coda’s info.plist file, that identifier is com.panic.coda.css.

And that identifier is wrong, because CSS is not Panic’s format.

I use CSSEdit. Currently, it doesn’t declare a UTI, but if they should follow Coda’s example, they should make one up of their own, such as com.macrabbit.cssedit.css. Now we have one type with two names. Which is right?

Suppose I write an application that accepts CSS data. Which UTI do I look for: com.panic.coda.css or com.macrabbit.cssedit.css? Should I look for both of them? What if I find both? What if a third developer releases a CSS editor? Now I have to keep up with the entire population of Mac CSS editors just to accept all the many names for one type.

The right type identifier would be something like org.w3.css or org.w3.cascading-style-sheets, following the rule that the type should be named after whoever controls it. The W3C controls CSS, so its UTI should be named after them. Some other formats, such as PNG, aren’t controlled by anybody, so they go in public.

You might point out public.html and public.xml, as both of those are also controlled by the W3C. Obviously, I disagree that these should be in public.*. But it’s too late to change them now, so we have to put up with them.

Better examples include com.adobe.pdf and com.microsoft.word.doc. In each of these cases, some third party controls the format, so they get the format’s UTI named for them. Notice that Preview does not invent a com.apple.preview.pdf UTI, and TextEdit does not invent a com.apple.textedit.word.doc UTI; they use the UTIs named for the creators and maintainers of those types.

So now we see a problem. All the text-ish files have the same type identifier: com.apple.traditional-mac-plain-text.

Because they are all the same type. And that type is named after Apple because Apple controls that format (in this case, a text encoding).

The Photoshop PNG file is typed as public.png.

There’s no such thing as a “Photoshop PNG” file. PNG is an open format controlled by no-one (or, arguably, the W3C, in which case the type should have been named for them). What you have is a PNG file that you created in Photoshop. That latter detail is irrelevant to its type, which is why HFS had the creator code separate from the type code in the first place.

If there is such a thing as a “Photoshop PNG” file (that is, if Adobe incompatibly extends the PNG format in some way), then they should assign that format its own name (say, com.adobe.png), because it’s a different format.

If you take away the creator code, you’re screwed, because all you have are the extensions.

Exactly why John Gruber, Ross Carter, and Matt Neuberg don’t like the change.

Coda CSS file props:

displayed name:"test.css", 
creator type:"TStu", 
type identifier:"com.apple.traditional-mac-plain-text",

I’m surprised you didn’t notice this. Why isn’t this file’s type identifier com.panic.coda.css?

… why aren’t any of these applications doing the right things? Pages ’09 does. It sets the type for .pages files to “com.apple.iwork.pages.pages”.

Because it’s Apple’s own format specifically for Pages. Again, see also com.microsoft.word.doc.

Unsurprisingly, it doesn’t even have a creator code.

Yeah. Cocoa makes it difficult to apply a creator code to a file and doesn’t do it automatically, so expect most Cocoa apps to not do it.

Even thought the default for the .html extension is BBEdit, the UTI overrode that. When I changed the handler for public.html to BBEdit, then the file opened in BBEdit. That’s exactly the behavior I’d expect, and it matches what you got with Creator Codes.

It matches what you got when you assigned the default handler of a file type, as well. That’s what you did the newer equivalent of.

There never was a way to set which application opened files that had a given creator code. That was what the creator code was for: Determining which application would opened the file.

Yes, Apple did abruptly kill off Creator Codes, however, they’ve been warning about that for some time now.

Sort of. They’ve been warning that they’d kill off the combination of file type codes and creator codes. UTIs are the replacement for file type codes; as I said above, there is none for creator codes.

Now, I know that ‘simple’ is a big fat lie when it comes to application development, however, at some point during the 10.5 lifecycle, all these applications should have been updated to not only support UTIs, but to use them. Instead, they all relied overmuch on FIle Types/Creator Codes …

Actually, it was more common to use filename extensions. See what I said above about the difficulty of assigning file types and creator codes from a Cocoa app. I think that was actually quite rare, simply because filename extensions were so much easier.

… and now that those are gone, well, the OS does what it can with the information it has available.

No, it doesn’t. The creator code information is still available, and the OS ignores it. The OS now only uses type information to determine how to open a given file, except for files that the user has assigned a specific application to.

Oh, and what about when you change a file association in the Finder? Well, unsurprisingly, the Finder cheats. It adds a resource fork to the file with the path to the desired application coded within. … [M]aybe the Finder could start doing the right thing too?

Agreed. I say it should set the file’s creator code.

Incidentally, I tested in Tiger, Leopard, and Snow Leopard, and Finder did this resource trick in all three versions. If the Info window ever did set the file’s creator code, it hasn’t done that for many years.

If the only way to have a unique UTI associated to a file is for that file to use a completely unique file extension, then WHAT THE FUCK GOOD ARE UTIS? Fucking seriously, why the FUCK bother? BBEdit creates TEXT FILES. Does Apple seriously expect that Bare Bones, to properly use UTIs, is going to now create a .bbedittext extension, a .bbedithtml extension, a .bbeditohmyfuckinggodwhatthefuckisgoingon extension, then make you EXPORT to ‘standard’ extensions, just so you can know a file created in BBEdit will open in it?

And now you know why smashing type information and creator/opener information into a single value is a bad thing.

If this is what Apple is pushing, then everyone who signed off on non-settable UTIs is a fucking idiot…

There is no reason why the average user should be able to change the type of a file. If they created an HTML file, it’s an HTML file, and there’s no reason for a user to be able to set it to anything different unless they really know what they’re doing. (I’ve done it, and I’m assuming you have, too. We’re exceptions.)

What you want to do is to change which application opens the HTML file, and that is completely separate from the fact that the file contains HTML.

The new version of TimeMachineGrowler includes compatibility with Snow Leopard and a few fixes. Plus, I’ve created a Google group for it, so you can get news of any further updates there.

Just in time for tomorrow’s release of Snow Leopard, TimeMachineGrowler is an app that will tell you how long Time Machine takes to create a back-up by posting Growl notifications when the back-up starts and finishes.

One of the promised “refinements” in Snow Leopard is faster back-ups, so you may find it interesting to compare how long a back-up takes on your machine running Leopard to how long it takes on Snow Leopard (assuming, of course, that you haven’t already abandoned Leopard for the Snow Leopard GM).

UPDATE 2009-08-14: Or just use CopyPath, which looks like a much better implementation of exactly the same thing. Thanks to David Keegan, its author, for suggesting it in the comments.

The original post content follows.

This is a script application, which apparently you can drag into your Finder toolbar. (If it doesn’t let you, you didn’t drop it in the right spot. Finder is finicky about this. Keep trying.)

Once you’ve added it to your toolbar, you can just click on it to run it. The script will copy the UNIX path of whatever you have selected in Finder to the clipboard.

Inspired by a conversation with Alan Boyd.

This October 17th and 18th, there’s a conference for iPhone developers in Boston, which the organizers asked me to attend.

The conference is called Voices That Matter: iPhone Developers Conference, and the titular voices include Aaron Hillegass (famous for his book), Erica Sadun (famous and infamous for her jailbreak work and advocacy), Bill Dudney (famous for his book), Stephen Kochan (somewhat famous for his book), Jonathan “Wolf” Rentzsch, Fraser Speirs, and Daniel Jalkut.

As most of you know, I’m not an iPhone developer—I write for the Mac only. So I declined that part of the offer.

The other part was a coupon for you, my readers. I know many of you probably are iPhone developers, so I asked whether they would still like me to give you that coupon code. They agreed, so here it is:

PHBLOG

(Those of you who read Jesper’s weblog may recognize it.)

Without the coupon, the registration fee is $495 until September 12th, $695 thereafter. The Word document they sent me says that that the coupon will knock $100 off.

Enjoy the conference!

PlistBuddy(8) is a command-line tool for editing property-list files, with a deeper reach than plutil defaults:

Entries consist of property key names delimited by colons. Array items are specified by a zero-based integer index. Examples:

  :CFBundleShortVersionString
  :CFBundleDocumentTypes:2:CFBundleTypeExtensions

Jonathan “Wolf” Rentzsch, in his del.icio.us bookmark for the manpage, says that PlistBuddy is “always at /usr/libexec/PlistBuddy on modern systems”.

In the first three months of this year, I’ve downloaded 2927 free songs. That’s not including the recent label samplers from the Amazon MP3 Store, nor the thousand-song influx that is the SXSW 2009 torrents.

From this, I estimate that I will download over 11,000 songs in this year alone.

My library right now, including everything I’ve ever bought, is 10,626 songs. Subtracting the 2927 mentioned above, I have 7699 songs that I didn’t get this year, or didn’t get for free. This means that this year’s free music will have multiplied the size of my library by about 250%.

I say this not to brag, but because my mind is blown. I’m going to more than double my library this year, for free. Legally. Without pirating a single song.

Wow.

There’s no reason for anyone to pirate music anymore. Music DRM is dead, so the “moral” argument is gone, and you can get as much music as you can listen to without having to spend one red cent. If you have a specific song in mind, you usually can buy it from iTunes or Amazon—and if you don’t have the money to do that, why are you pirating music instead of looking for a job?

I do worry that this could backfire on artists. I barely have enough time to listen to everything I get for free, so I never listen to the rest of the songs on the album, which means I never buy the album. If enough people did what I do, the music economy would collapse.

You might say “why not just donate money to the artists?”. The main reason is, again, my limited time. Getting, tagging, and listening to all this free music takes up more spare time than I’d like already; now you’re proposing that I spend more time just to spend some money. I don’t feel guilty enough.

Two other reasons are that I don’t like donating money in exchange for nothing (the song was free), nor paying for things I already have. I’d rather buy the album, because then, I’m buying something I don’t already have.

Radio Paradise works well here. I hear songs that I like and must buy to have, and I buy them. This way actually makes money for artists.

But Radio Paradise isn’t perfect. The main problem, yet again, is that time issue: I no longer have much time at my computer when I’m not listening to fresh free music, and when such time does arrive, I usually use it to listen to what I already have (a rare break from the endless stream of new stuff). Radio Paradise loses badly in my schedule.

I take comfort in the possibility that I’m an outlier: the only one actually gathering as many of these songs as I do, while everyone else is content to only tap a few sources (e.g., iTunes + Amazon) and make up the rest with purchases. The artists get their due compensation, and I get my free music.

Still, I can’t shake the feeling that there must be some better way.

Here’s something an artist could try: Set up a combination player and online store on your website. Let me listen to the entire album for free. Let me download any, say, two songs for free. If I want more than that, I have to pony up for the whole thing.

Another way would be something more like iTunes and Amazon, but with a much longer preview—let’s say half the song. I don’t know about you, but I find 30 seconds useless. With half-song previews, I could get a good sense of the song and whether I want it in my library, but it wouldn’t be worth just downloading the preview and adding that, since it’s only half the song.

The problem with both these solutions is that they, too, compete for time. I’m not sure I’d find it worth it for one artist. Perhaps a record label or independent online music store (like Insound) would be willing to try it.

The best solution I can think of would combine one of the above solutions with a streaming internet-radio player. I could open a browser window (or SSB) upon the player, and leave it running in the background. If I hear something I like, I could bookmark it, so that I could come back to it later to listen to it again, listen to the album (the whole thing, straight through), buy the song, buy the album, recommend the song on Twitter, or dismiss it.

What do you think? Am I inadvertently screwing over artists in these ideas? Should I stop looking the gift horses in the mouth and just take my free music? Are there better solutions than what I’ve suggested?

UPDATE 12:07 PDT: Just found this by random encounter: Amie Street, an experimental new music store. Its twist is that every song starts out “free or very cheap”, and goes up in price as more people buy it. Talk about demand-driven. I haven’t tried it, though—if any of you have, please speak up.

copyfile(3) is an API for copying and moving files within the file-system:

DESCRIPTION

These functions are used to copy a file’s data and/or metadata. (Metadata consists of permissions, extended attributes, access control lists, and so forth.)

The copyfile() function can copy the named from file to the named to file; the fcopyfile() function does the same, but using the file descriptors of already-opened files.

The copyfile() and fcopyfile() functions can also have their behavior modified by the following flags:

COPYFILE_CHECK

Return a bitmask (corresponding to the flags argument) indicating which contents would be copied; no data are actually copied. (E.g., if flags was set to COPYFILE_CHECK|COPYFILE_METADATA, and the from file had extended attributes but no ACLs, the return value would be COPYFILE_XATTR.)

COPYFILE_PACK

Serialize the from file. The to file is an AppleDouble-format file.

COPYFILE_UNPACK

Unserialize the from file. The from file is an AppleDouble-format file; the to file will have the extended attributes, ACLs, resource fork, and FinderInfo data from the to file, regardless of the flags argument passed in.

File Manager also has APIs for copying files, in both asynchronous and synchronous flavors. Those APIs don’t provide as much control over management of metadata, but they do offer asynchronous operation, whereas the copyfile(3) APIs appear to be synchronous.

And, of course, I should mention NSWorkspace operations, which you use with the performFileOperation:source:destination:files:tag:
method. Unlike the other two, this API has been around since 10.0. On the other hand, like copyfile(3), it’s synchronous only.

The Common Crypto library in Mac OS X 10.4 and later provides simple APIs for five SHA algorithms:

CC_SHA1() computes the SHA-1 message digest of the len bytes at data and places it in md (which must have space for CC_SHA1_DIGEST_LENGTH == 20 bytes of output). It returns the md pointer.

CC_SHA1_Init() initializes a CC_SHA1_CTX structure.

CC_SHA1_Update() can be called repeatedly with chunks of the message to be hashed (len bytes at data).

CC_SHA1_Final() places the message digest in md, which must have space for CC_SHA1_DIGEST_LENGTH == 20 bytes of output, and erases the CC_SHA1_CTX.

The successor versions of SHA-1, SHA-2, are also implemented for hash bit lengths of 224, 256, 384, and 512. The functions to call to invoke the larger hash-size versions of the algorithms include the hash size as part of the function names: …

RETURN VALUES

All routines return 1 except for the one-shot routines ( CC_SHA1(), etc.), which return the pointer passed in via the md parameter.

Christopher Bowns pointed out (thanks!) that Jonathan Rentzsch released ClickToFlash 1.2 yesterday.

This is the first version that incorporates any significant features from my fork. Specifically:

• It now loads the Flash movie on mouse-up, not mouse-down.
• It now draws the ClickToFlash view as concave when the mouse is down and within its bounds.
• It now has a separator item in the contextual menu.

The first two of these came from my tree, a fact that I am very happy about. The last one he pulled from Troy Gaul’s tree instead, but it makes no difference, as it’s just an element in a xib document.

If you’re using 1.1+boredzo, you don’t need to upgrade. My version of 1.1 has all the features of his 1.2, plus the “Copy Address” contextual menu item and, of course, my own click-to-play symbol.

My fork of Jonathan Rentzsch’s adopted WebKit plug-in lives on, as I release my version of ClickToFlash 1.1.

So far, he has not pulled any of my changes into his tree, so the list of features unique to my version has only grown:

• It loads the Flash movie on mouse-up, not mouse-down, giving you a chance to back out by moving your mouse cursor off of the movie placeholder.

• It changes to a concave appearance when you press the mouse on the placeholder, making it look, as well as act, more like a button.

• It has a better (IMO) click-to-play image. (Screenshots on the other post.)

• It adds a separator menu item to the contextual menu. (New in 1.1+boredzo, and the menu itself is new in 1.1)

• It adds a “Copy address” menu item to the contextual menu (along with another separator). (New in 1.1+boredzo)

• It incorporates Jason Foreman’s fix for websites such as thedailyshow.com. According to him, that simple change fixes ClickToFlash on a lot of websites; I can vouch for it on thedailyshow.com, at least. (New in 1.1+boredzo)