I’ve been beavering away on Neu, and the result is version 1.0b17, which you can download here.

There are three main changes for this version:

First, I’ve changed the “Create Document…” and “Create and Open Document…” menu items. They are now submenus which contain a “Choose Template…” command, but also contain a list of the actual templates. This allows you to choose a template directly without going through any additional dialogs.

Second, I’ve added these menus to the Neu menu in the Dock, and the small status menu that Neu can optionally show on the top right of the menu bar. This means that you can use these menus instead of the Finder’s Services menu. Since the Services menu is a bit clunky and can’t contain dynamically generated content, this is a Good Thing(tm).

Finally, I’ve added “Protect from accidental Quit” option which changes the Quit menu shortcut to Cmd-Shift-Q instead of Cmd-Q. This makes it harder to accidentally quit Neu, if you want to leave it running all the time.

I discovered that there’s already a piece of software out there called Replicator, so it now has a new name.

In fact, it doesn’t just have a new name, it has a neu name, since the new name is Neu.

Still with me?

Visit the Neu (the application formerly known as Replicator) homepage for more details.

Update:

I forgot to mention that the change of name broke the auto-updating mechanism, so you will need to manually download it again.

Hot on the heels of the previous blog post… it turns out that there was a bit of a major bug in 1.0b14, so 1.0b15 is now out.

If you managed to download 1.0b14, then the automatic update process should get you to 1.0b15.

If not, you can download the new one here.

Visit the Neu (the application formerly known as Replicator) homepage for more details.

I’ve just released the latest update to Replicator, a utility that lets you create new documents directly from the Finder, using predefined stationary.

The new version (1.0b13) lets you choose the template to replicate using a grid view, rather than a list view, which looks a bit cleaner and reduces the likelihood of nasty scrollbars appearing.

If you’ve got an existing version, it should pick up the update automatically when you next run it. If not, you can grab it from here) page.

When I’m developing something, I like to split out related functionality into modules or libraries whenever I see the opportunity, so that I can share code between projects and generally promote re-use.

Doing this presents a number of interesting challenges, one of which is how to manage changes to these shared modules.

If I have three projects using some module, I can either choose to have them all link to the same version of the module on my disk, or I can give each project its own copy.

On the face of it, linking to the same version sounds like the way to go. After all, we’re sharing right? If we make a fix to the shared module, we want to get it in all projects don’t we?

Well, sort of, but not really. It’s how I used to do it, but not any more, and I’ll explain why in a moment.