Category: Hazel


Antisocial Software

November 7th, 2006 — 12:10am

Unless you installed your operating system from floppies, chances are that you have a bunch of programs running on your computer at any one time. There are enough things that can go wrong in any one particular program and when you add them into the same soup, the interactions between them create more scenarios where things can go awry. The operating system has ways of preventing programs from mucking with each other via protected memory and resource limits but it’s not that surprising when some program will interfere with another.

It’s something I have to deal with a lot with Hazel. Since Hazel runs in the background and manipulates files it does not have full control over, there’s a lot to be watch out for. I have to coordinate with browsers to make sure not to move the file while it’s still being downloaded. I try and detect when the user is copying something with the Finder (which for some reason uses ‘brok’ as the file type instead of the ‘bzy ‘ or ‘bzy?’ types which I believe was the convention from the older MacOS days). I run my background processes with lower priority and even use low priority IO. Try this test. Take a large file and copy it. Turn off Hazel’s trash management options, move one of the files to the trash and use Finder’s “Secure Empty Trash”. Observe how usable your machine is while this is happening (for me, the answer is “barely”). Now, turn on Hazel’s trash management, setting the trash size threshold to something lower than the file size. Set Hazel to throw away oversized files immediately and to do so securely. Now, throw away the other file. You can tell something is happening but at least from all my tests, my machine is more responsive.

So, it’s a bit frustrating when you go through the trouble of making your software a good citizen when someone else’s software goes out of their way to interfere with yours.

A while back, I got a report from a customer that Hazel was not working. Looking at the logs, the customer noticed that it would stop working whenever he ran Logic Pro. When he quit Logic, Hazel would magically work again. At first, I didn’t believe it. It seemed too weird but I downloaded a trial of Logic Express and sure enough, I experienced the exact same behavior. After a bit of poking around I discovered what was happening. Logic Pro/Express stops all launchd jobs. Hazel uses launchd to start its background processes so it was a bit disconcerting to see another program, especially one from Apple, disabling yours on purpose, albeit indirectly. At least Logic is nice enough to start the jobs again when it quits.

Now, I’m sure the Logic team is probably doing this to ensure a level of performance but scouring the Apple lists and the web at large turned up nothing about this behavior. Maybe a tech note somewhere would have been nice. It’s unclear if any of Apple’s other pro apps exhibit this behavior but at least now I know what to look for.

Should this be a preference in Logic? Maybe a warning when it detects that the user has their own launchd jobs? I know it’s not common for software out there to depend on launchd but it is pretty annoying for those of us it does affect. I could write my own daemon using kqueue (which launchd uses to monitor file changes). Logic will not interfere with it then, but part of me feels that this would make Hazel impolite. Logic is doing what it’s doing for a reason and to work around its intentions goes against Hazel’s good manners. So for the time being, I’ll just have to accept that the housekeeper must go on break whenever the cops come in to commandeer the house.

Comment » | Hazel, OS X, Programming

Hazel 1.1

October 26th, 2006 — 8:03pm

It’s here. A bunch of improvements and fixes, including the ability for rules to execute Automator workflows, AppleScript and shell scripts. Since this blog is a bit more developer oriented, maybe one of you out there can come up with some interesting scripts.

This release also incorporates Sparkle for software updates. In actuality, I’m using the Sparkle+ variant, though I’m not using the system profiling aspect of it. If any of you are developing a pref pane and want to incorporate Sparkle, feel free to drop me a line as you have to change a few things. Tom Harrington, who is the maintainer of Sparkle+ also has experience doing this but I’m not going to volunteer him for questions though if you join the Sparkle+ mailing list I’m sure he’ll answer them.

In short: Sparkle good. In retrospect, I should have included it from the beginning since you get problems when installing a pref pane over itself. I know that Objective-C can’t unload classes but you’d think that System Preferences would restart when this happens. It does detect it since it asks the user if they want to install over the old one.

At the risk of raising the ire of those Geico cavemen: Download. Buy. *grunt*

Comment » | Hazel, Noodlesoft, Software

Paths to Enlightenment

September 26th, 2006 — 7:36pm

An issue I’ve been dealing with is displaying a file path to the user. While this may be strongly discouraged (anyone have a cite from official Apple documents?), you have to admit that having a compact visual representation is useful at times.

With OS X being a collision of sorts between UNIX and the older Mac OS, there are two ways most programmers would conceive of a file path. The UNIX way would use slashes (/) with no drive at the root. In the Mac OS way, you’d have a drive at the root and colons (:) to separate the parts of the path. It was my impression that colons were on the way out but at the same time UNIX paths did not seem appropriate for regular users.

Trying to find examples in OS X itself, you find that inklings of both appear depending on where you look. For instance, doing “Get Info” on a file in Finder gives you the UNIX path. Command-clicking on the title of the Finder window gives you a pop up of all the ancestors of the currently shown file in the more Mac OS style (it shows the drive). The open and save panels have the same thing in the pop-up up top. No colons though.

Things get a bit more interesting when English is not your primary language. Set Spanish as your primary language in System Preferences and look at your sidebar. Notice anything different? Common folders are now translated. “Music” is now “Música”. “Movies” is now “Películas”. You no longer have a Desktop, you have an Escritorio. Now, this isn’t the problem (for programmers) that you think it is in terms of having to localize references to these paths. Just jump into Terminal or even do a “Get Info” on the file and you see the same UNIX path you’d see if everything were in English. These translations only exist to the user. That said, it would be nice when displaying a path to use the one the user would most likely understand so UNIX paths are out.

Now, let’s look at NSFileManager. There are two methods for getting a display version of a path:

– displayNameAtPath:
– componentsToDisplayForPath:

The odd thing here is that you cannot get a string with the whole path. -displayNameAtPath: only returns a translation of the last path component. -componentsToDisplayForPath: returns an array of the components. In both cases, they skirt the issue of what to use as a path separator.

In the current version of Hazel, I punted and just used what was shown in “Get Info”, which is the UNIX path (BTW, to show the full path in Hazel, just hover your mouse over a folder). Recently, though I caught Finder in the act of displaying a path.

Try this: drag a file into that space in the Finder window between the toolbar buttons and the search field. For those that don’t know about this feature, it’s basically a place where you can stick files that you can quickly access later. For you NeXTSTEP people, it’s a poor man’s shelf.

Now hover your mouse over the file on the “shelf”. There it is. Not a slash. Not a colon. The path separator is a triangle pointing right (▸). That’s unicode character 0x25B8, for those keeping score at home. You can see this somewhat echoed in Finder when you do a search. When you click on one of the results, you get that nifty path widget at the bottom with different triangles, but triangles nonetheless.

So is this standard? Dunno, but it’s good enough for my purposes and I’ve stuck it in the next version of Hazel (I’ve also added a contextual “Reveal in Finder” menu item for those that want to view the folder in context in Finder). If you see file paths popping up anywhere else, let me know.

3 comments » | Cocoa, Hazel, OS X, Programming

Back to top