The bundle contains 10 apps for a single low price of just $39.99
If you’re doing web design, there’s probably something here for you
(unless you already own all the apps, in which case, it also makes a great gift)

The bundle includes:

• Get Backup Pro
• skEdit
• Better Link Tester
• Simon (Bronze – 15 active tests)
• Logo Design Studio Pro
• Stor
• Interarchy
• Whoosh
• MacFreelance
• HTMLValidator

The offer is running until December 28th, so you will have to be quick, or you might miss out!

This problem may happen if you return YES from validateMenuItem in a NSDocument subclass for menu items that you don’t actually control. (If you just return YES as a default for example)

If instead you return

[super validateMenuItem:item]

You should get the correct “Revert to Last Saved Version” menu item

I ran into this when I was doing testing on 10.7 and although documentation clearly states that you must call the super method in validateMenuItem: , it wasn’t immediately obvious to me what was causing the problem.

Hope this helps if you have the same problem.

Edit: This may have been fixed in OS X

However this last week I saw something really surprising; Runesoft has released a patch to bring Intel compatibility to the game and it now works on Lion

I’m really impressed with this, thank you Runesoft!

What it should ideally do is to automatically update using Sparkle or similar. I don’t want it to check constantly in the background, simply check and update when I click the “check Now” button.

Failing that, it should clearly state whether the current installation is up-to-date or not.
I don’t want to have to compare version numbers on a page that lists 8 different product version numbers. The software knows which variant it is, its own version number and a web service can be provided to display the latest numbers. It’s trivial to download the latest version number and test to see if it is the same as the installed version, then provide a direct download link if it isn’t.

In fairness some progress has been made in flash installing, at least they now include a standard pkg installer and progress is being made on providing release notes. But much more progress (or the demise of Flash) is still clearly needed.

The change initially is significant, and there were new ways of doing things and certain other things that had to be rethought altogether. But now, I’m starting to choose to use Xcode 4 when I have the choice, so I think I’ve got used to it

I recently released some new project files for Tesseract OCR cocoa, and they are built with Xcode 4 now. The simplification in the build system and the linking of the frameworks is a vast improvement. Workspaces are a gift to this type of multi-project build.

The only issue I have is that it doesn’t support 10.5 or PPC, so SQLEditor is stuck on Xcode 3 for a while longer.

Things seem to be going well. SQLEditor appears to work correctly.

There is one identified issue which means that you cannot register the app for all users of a machine. Each user must register the app separately in their own account. (This is due to the /Library/Preferences directory now only being writable by root).

This doesn’t affect Macs which are already registered. Administrators can also manually set the preference keys in the
/Library/Prefererences/com.malcolmhardie.sqleditor.cocoa.plist
file to register for all users.

This problem will probably fixed by making the registration process separate and running it with higher permissions.

HTMLValidator still needs some more work and isn’t currently compatible. A revised version is in the works and should be available soon.

TesseractOCR seems to be working fine (and if you haven’t seen them, please check out the xcode 4 source release, it’s a big improvement)

The answer is that I expect that SQLEditor will be compatible with OS X 10.7 when it is released in July.

There is a new page up on the support site about this,

Why?

• Zip files are simpler to create
• It prevents the problem of the app being run from the dmg
• Safari handles zip downloads really nicely
• Disk images created in 10.6 tend to loose their background images in 10.5

That last problem is quite significant, because most of the friendliness of the dmg is the background image; if you loose that, you might as well have a zip file.

There are some benefits from dmg files:

• They have the background image and the drag to applications directory install
• DMG files can be smaller
• DMG files are handy to store

But then if you loose the first point anyway, it might not be worth bothering.

Now there are excellent tools like DMG Canvas for creating cross platform disk images that work fine and keep their background images, but I began to wonder if it was worth the effort for SQLEditor. Were the benefits of the background image sufficient to make up for the trouble?

Various notables including John Gruber, Panic and Sofa recommend or use zip files, so it’s becoming more popular. (The Mac App Store uses pkg but it’s a different story altogether)

The change isn’t actually as significant as it seems anyway, because SQLEditor has been available in both zip and dmg formats for some months now. The release process automatically builds both zip and dmg format archives and uploads them at the end of the build release process. The change is really just that the website links now point to the zip instead of the dmg. (And if you really want the dmg you can change zip to dmg in the download link and get a dmg)

Enjoy!

Or take absolutely no notice of it at all

The reality is that one particular Java runtime has been deprecated: the one that Apple write themselves. Java as a language will still be available, only it won’t be Apple that writes it and possibly it might be an optional download.

The confusion is because up until now there has really been only one Java runtime on the Mac, which Apple wrote themselves using code licensed from Sun. Now Apple has chosen to discontinue their own particular runtime, but this doesn’t mean that there won’t be any Java at all.

There are already alternatives, in particular the OpenJDK and SoyLatte variants; a little rough in places possibly, but they definitely work. Undoubtably in time they will improve and others will appear, including possibly an Oracle one.

Obviously it would have been nice to have the deprecation notice and an endorsement of another runtime made at the same time, but given how long it will be until the current runtime becomes unsupported, I’m not terribly concerned.

Also, whether such a future Java release has a native visual appearance is not of virtal importance. While the Apple Java team has made enormous efforts to get it to look and feel native, it takes quite a bit of work to create an application that looks seamless. The very first version of SQLEditor was a Java Swing application and although it looked fairly good, it was taking too much time making things match exactly. Switching it to a native cocoa application made my life much easier (but killed off any immediate hopes of a Windows version)

I think most people accept that Java Swing apps don’t look native and will accept that the visual appearance will differ.If you want a truly native feeling Java app in the future you should look at SWT or better Rococoa, not Swing.

What is important is that future Java runtimes don’t require X11 for Swing. But I’ve seen good progress by several projects towards this goal and I’m not worried about it either.

Ideally of course, Apple would release their Java Runtime as open source, but whether they are in a position to do that with respect to licensing is unclear.

Having seen the deprecation notice last week and been somewhat concerned, I’m now fairly confident about the future of Java on the Mac,