Normally last Friday would have been my last day and I would have returned to uni to complete my degree, but a couple of months ago Sun offered me the chance to stay on another year and I jumped at the chance. I figured that the chance to work for Sun for another year and still continue with my degree at university on a part time basis was too good to pass up. Apart from this and although I'm still technically an intern I amazed at the amount of responsibility I am given (in terms of the projects that I work on) as well as the fact that I am treated just like every other member of the team, are the things I think I would genuinely miss if I were to leave.

Anyway, I'm starting to bore you. Heres to the next year, I'm sure it'll be just as good as the first, if not better.

• Issue affecting some users that prevented SafariTabs' preference pane being loaded and displayed.
• No tabs being restored when deselecting all tabs then cancelling the tab view and selecting to restore all tabs.

The first, as far as I am aware only affects a few users and as of yet I'm still not entirely sure why (I can't be certain but its mostly likely being caused by SafariTabs being incorrectly loaded by SIMBL). The fix inluded in this release should mean that the preference pane is now always loaded.

The second fix is for an issue that really only exhibits itself after completing a certain set of steps as outlined above, and was discovered whilist I was testing this release.

In terms of new features, there are none in this release and in general I've kind of run out of ideas for any new ones that are just tab related. So please, if you have any that you think might make a nice addition to SafariTabs or any other feedback for that matter then just let me know.

I've now moved them down a level to get around some issues that were bugging me and are now accessible via:

The things that were bugging me were the problems that arise when attempting to use Apache's mod_rewrite for URL re-writing with repositories installed on the domain. If you've ever setup a repository to be HTTP accessible then your probably aware that it doesn't exactly act like a normal directory on disk and so re-writing URLs that include conditions to check if the requested file or directory actually exists doesn't have the expected result. Hence changiing the URL on which the repositories are served on means I can catch these requests in my .htaccess file containing all my URL re-writing rules using the following as the very first entry:

RewriteCond %{REQUEST_URI} ^/svn/.*$
RewriteRule ^(.*)$ - [L]

Which basically prevents any other rules after this one being applied if the URL begins with /svn/.

Also, I've enabled repository access via the svn:// protocol in addition to HTTP, so all repositories can now be accessed using:

Probably a bit more than anyone really needed to know but hopefully it will be useful to someone out there and its also a good example of what happens when I get bored and start messing about with things.

In my view if I register a directory to ignore events from (that is, a directory that is a sub-directory of the paths I registered to watch) then I also want to ignore the events that originate from sub-directories of this path. Using the example from my previous post, if I rgister my application to be notified of all all events that occur under the current user's home directory but I want to ignore those events that come from their Downloads directory then I will, but version 0.1.1 will notify my application of events from directories within the Downloads directory. By default version 0.1.2 will also ignore these events but because this may not always be the case, for example, your application truly does want to ignore a specific directory and doesn't care about sub-directories then there is a new option to enable or disable this behaviour. Simply use the following method:

My thanks go to Simon Wolf for providing a lot of valuable feedback that has resulted in many of SCEvents' new functionality and improvements. Cheers Simon.

SCEvents *events = [SCEvents sharedPathWatcher];

[events setDelegate:self];

NSMutableArray *paths = [NSMutableArray array];
NSMutableArray *excludePaths = [NSMutableArray array];

[paths addObject:NSHomeDirectory()];
[excludePaths addObject:[NSHomeDirectory() stringByAppendingString:@"/Downloads"]];

[events setExcludedPaths:excludePaths];
[events startWatchingPaths:paths];

One other change that has been made is the removal of the trailing slash on all event paths that are provided to the client application. FSEvents provides the event paths with a trailing slash presumably to indicate that the event originated from within that directory but the removal of them enables SCEvents to provide the above functionality of ignoring events from particular directories. Therefore, client applications that register to ignore directories should provide their paths with no trailing slash.

Also, one thing I forgot to mention when I originally released the code was that your project will have to be linked against the Core Services framework which provides access to the FSEvents API. You can do this by adding the framework to your project, it is located at:

Please also be aware that the sample project included in the source was created in Xcode 3.1 beta and probably won't work in any other version. To get around this simply create a new project and include the source files. The addition of this new functionality was the direct result of feedback based on usage so please keep it coming.

So where does SCEvents come in? Well as mentioned its an Objective-C wrapper around the C interface and allows you to utilise the full power of FSEvents in only a few lines of code. The design of SCEvents is relatively simple and is largely inspired by Uli Kusterer's excellent UKKQueue wrapper around the kqueue file change notification mechanism, which by the way I would definitely recommend checking out if you are interested in finding out when specific files change rather than directories. SCEvents is similar in the sense that clients that register to be notified of events implement the only method of the SCEventListenerProtocol which in turn passes along an instance of SCEvent representing the event that just occurred.

The source includes an example foundation application that simply registers the user's home directory for events then prints them to the console whenever they occur. It can be downloaded from my new source code page, but the most update-to-date version can always be found in my Subversion source repository at dev.stuconnolly.com. SCEvents is by no means perfect so I'm looking for feedback on ways it can be improved, so please check it out and let me know what you think.

Although I'm really enjoying using Twitter, at the moment it kind of feels like I'm shouting into a void so followers are welcome.

Also, I got a little bored last weekend and ended up writing my own twitter feed to display my latest tweets on this site. They can be seen at the bottom of the blog index and archive pages. The code behind it is pretty lightweight and works surprisingly well, but I've gone against the idea of releasing it publicly as its not really designed to be a plugin (like Twitter Tools for WordPress) and requires a little more manual effort than simply activating. That said if anyone is still interested in using the code just drop me an email and I'll be happy to help out.

A more stable implementation of the 'force new window links in a new tab' or single window mode feature was a key area of focus resulting in the resolution of various annoyances caused by pop-up windows created using JavaScript. This feature now only captures windows that are created from links with the target '_blank'. Turns out Safari 3.1 adds this exact functionality as a hidden preference, although issuing commands at the terminal or editing Safari's preference file is still required. It is still included in SafariTabs as an easy way for people to enable as well as to provide the additional feature of having the new tabs load in the background.

As always, for a more detailed view of the changes in this release please see the version history. Feedback, bug reports and feature requests are also always welcome.

SIMBL is right not to load SafariTabs as it is indeed not compatible with Safari 3.1, but just to let everyone know that I've not given up on SafariTabs having not released an update upon the Safari release, I am actually working hard on the new version which will eventually be SafariTabs 0.6.1. SafariTabs 0.6 does actually work with Safari 3.1 with the exception of a few features, its simply a configuration setting that SIMBL checks that prevents the plugin from being loaded.

For nearly all of the users that have contacted me about SafariTabs' incompatibility I have clearly stated this exact point as well as the fact that there is way around it and the steps to implementing this workaround if they are willing to live with the lack of a few features until a new release is available. The point of this post is to not only reassure all of the users of SafariTabs that a new version is being worked on and is on its way very soon, but also to provide this workaround to a greater audience than simply a per individual basis in each email. It also gives me more time to actually work on SafariTabs than spending the time repeating myself in every email that I receive.

It may seem like I don't care and I don't want to hear from users having issues, but the reality is the exact opposite, I welcome and encourage feedback regrading all aspects of any of my projects. Its just an announcement/acknowledgment like this I think is required to make everyone aware of the situation, not just those who contact me.

Having said this, the following is a quick guide that I have provided users when asked about SafariTabs incompatibility with Safari 3.1. Basically, SIMBL uses a custom entry within a bundle's Info.plist file which indicates the maximum and minimum build versions of the targeted application (in this case Safari) that the plugin has been tested with. SIMBL tests the plugin against the current application's build version and loads it based on its success. You simply need to change the maximum build version of Safari that SafariTabs has supposedly been tested with in order for SIMBL to load it. The following is how:

1. View the contents of the SafariTabs bundle by Ctrl/right-clicking SafariTabs.bundle and selecting 'Show Package Contents' from the menu.
2. Open the Info.plist file located at Contents/Info.plist.
3. Edit the MaxBundleVersion key contents to end in 25 rather than 23 found under the parent key SIMBLTargetApplications.
4. Save the file and restart Safari.

I must say that this workaround should only be used if you cannot wait for the new version of SafariTabs and you are comfortable with editing the contents of the bundle. The workaround is intended for users who have stated to me that they can't use Safari without it and don't need the missing fetures.

The new version is progressing nicely and the delay is largely down to the fact that I want to resolve all the bugs and issues that were brought to light in the current release. The final product should provide an improved user experience than some users may have had with new features introduced in the previous release.