I’ve released another two betas of Ambientweet in the last couple of days, and hopefully it’s now getting close to being ready for submission to the Mac App store.

The current plan is still to release it as a free app to begin with, as the main thing I’m interested in at this stage is getting a bit of feedback.

It’s been a while since I’ve had a chance to do much to Ambientweet, but it’s still trundling along in the background. It’s a fairly experimental project, and as such it definitely suffers a bit from the “there’s one more thing” syndrome.

In other words, every time I think it’s time to release it, I have another idea (or spot another bug).

Having said that, hopefully you’ll find that the latest version is fairly close to being ready for submission to the store.

As always, any feedback appreciated…

I’m happy to say that Neu 1.1.1 has been released, and is now available from this website and Apple’s Mac Application Store.

This version is pretty much the same as 1.1, except that it fixes a bug that caused the service names to have the wrong values. See the release notes for full details.

For those who don’t know, Sandboxing is a new facility introduced in Mac OS X Lion, which requires applications to list what abilities they want from the system, and then restricts them at runtime so that they can’t do other things. At the moment sandboxing is optional, but fairly soon it’s going to be obligatory for applications that are sold through the Mac Application Store (MAS).

I have a utility application (Neu), currently on sale in the MAS, which is going to run into major problems with sandboxing as it currently stands.

The utility allows the user to create files quickly from templates. Really it just does a glorified copy of a stationery file into a location of the user’s choosing - but it presents the user with a simplified interface for doing this.

The problem with sandboxing comes with how the utility chooses where to create the new file.

Initially Neu was written to be triggered by a Services menu selected from the Finder. It would then create the new file in the location represented by the Finder window that the user had open when they opened the services menu.

I am concerned that this may not work under sandboxing - unless the sandbox system automatically adds any paths that it supplies to an application to the list of allowed accesses.

However, there is a more serious problem. The Finder/Services integration isn’t brilliant, and in particular, there’s no way to right-click on a Finder window and have it show a services menu for the folder that the window represents (see rdar:7719410).

Because of this, I’ve added some other mechanisms for triggering Neu. These mechanisms rely on looking at the front window of the Finder, and inferring the location that the user wants to create files in from it.

I’m assuming that this isn’t going to work with sandboxing. Instead I’m going to have to throw up a “Save As” dialog and ask the user where to save the new file. This is already an option in Neu, but requiring it is going to annoy the users that turn it off by default.

It seems like sandboxing is a great idea, but if we’re not careful it is going to destroy a whole class of utilities which work by integrating with other applications. The Finder is the most obvious of these other applications, but I’m sure that there are many additional examples - for example utilities that watch what track is being played in iTunes, and then do something with it.

Because of this, I think we need the possibility of specifying an entitlement allowing the application to interact with another process id - in a way that then allows the application to do the sorts of things that I’ve described.

In the case of Neu, right now I’d have to request permission to interact with the Finder. However, in future versions I was also planning to allow Neu to infer a save location from the currently open document in the front application - thus letting it integrate more intelligently with whatever program the user is currently using. This would require yet-more flexible permissions.

I have some ideas for a different UI which will get round some of these problems for Neu, but these changes will only work at the expense of some of the intelligence that I had hoped to build into it. Essentially they will force the user to explicitly determine save locations at all times. This is a shame - there are times when we want the computer to make intelligent default choices for us. It seems like Sandboxing may curtail our ability to implement those default choices.

Unfortunately, because of persistent signups by spam users (probably driven by a script somewhere), I’ve decided to disable the facility to sign up to this site.

Really the only reason for allowing people to sign up in the first place was to in turn limit posting of comments and forums posts to registered users, again to avoid spam.

As a result, turning off sign-up may make it impossible for people to leave comments or use the forum. This is a real shame, but the alternative is just too annoying to police. In the meantime I’ll look into some alternatives. I may re-enable anonymous posting, along with captcha forms, but I fear that doing so will also result in a torrent of spam.

Very irritating…