Older Path Finder entries

We need beta testers!

One of the more difficult things about being an independent software developer is making sure your software is as bug-free as possible. Note that I didn’t just say “bug-free” - if you believe the mythical completely bug-free application actually exists, I have some bridges, magic beans, and unicorns I’d like to sell you.

We ♥ you

Seriously, though, we couldn’t do what we do without the kindness of you, our customers. We rely on your feature requests to tell us what to work on, your license fees to help us feed our families and keep us in business, and your bug reports to help us fix Path Finder when it does something it’s not supposed to.

We already have an awesome group of folks helping us test Path Finder behind the scenes before we roll out a new release to the public, but we need help. With the release of Mac OS X 10.5 we are now in that strange and wonderful place where Path Finder supports two operating systems, and with that comes an even more complex testing environment.

We need you

We need your help kicking the tires whenever Steve adds a new feature, improves a new one, or rolls out a bug fix or workaround. Almost 60% of you have upgraded to Mac OS X 10.5, but that leaves 40% of you that are still using Mac OS X 10.4 and we need to make sure both operating systems (and both CPU types) are represented in our beta testing group.

Interested?

Here are the specifics:

• Beta testing is, for the moment, purely voluntary. We’ve talked about finding fun ways of thanking our beta testers but at the moment if you decide to help us, it’s for the love of playing with the most recent, cutting edge builds of Path Finder.
• Beta testing is inherently risky. You must follow the tao of backing up your system frequently. We try not to provide beta builds that could cause your computer to implode, but stuff happens.
• We require you to be involved. Obviously everyone is busy and the amount of involvement that any single person can commit to is variable, but we still expect that you’ll let us know if you find a bug and try to get us feedback when we need it.
• It’s all confidential. We don’t generally release beta builds to the public for a reason: they’re not ready for public consumption. We hope and expect that you’ll honour this by not sharing download URLs, builds, or any other pre-release information with people not on the list.
• Beta testing is open to licensed Path Finder 4 customers only. For now, at least.

We thank you

Update: Thank you! We got lots of applications and we’re digging through them now. We will get in touch with you if you were selected. Thanks a lot for your willingness to help us!

Our new Xserves

Our new shiny Xserves just arrived! I think we were probably among the first who bought them, literally as soon as the Apple Store re-opened after the announcement we went online to place the order.

Using Apple’s Xserve is so easy - even if you understand nothing about servers, you don’t need to. It is the server for the rest of us. You just basically deal with a familiar Mac interface over Remote Desktop. Everything is the same as on your Mac, you log in as usual, manipulate your files as usual (what do you think, we have Path Finder installed there too :) ). Of course if you’re of the geeky type, you can still administrate it the “normal” way, as you would any other server - via ssh in Terminal.

We were waiting for this update to renew our G5 Xserves that are faithfully handling our internal purchase system, bug tracker and source code repository. Since the current Xserves are in Los Angeles, and we wanted to migrate our servers to San Francisco, we figured it would be easier to buy new ones and sell old ones (by the way, if you’re interested - drop us an email).

Here are the specs of our new babies - btw, any ideas of good server names?

• Two 2.8GHz Quad-Core Intel Xeon (8-core)
• 8GB (4 x 2GB) RAM
• 2x 1TB drives
• Dual 750W Power Supplies

Here are some pictures of them in their boxes - they are pretty heavy! We will be busy putting those beautiful beasts in their racks over the next couple of days. We will add some unpacking picts by then too.

Update: here are the beasts as installed in their racks. We chose 365 main datacenter as our new colo, this is one of the most known and professional datacenters in San Francisco, where Craigslist, Technorati, Six Apart and some other big web companies happen to host their servers too.

How one word of code for Leopard can break something on Tiger

The bug

Update: the issue that I was talking about here is now fixed in the freshly released Path Finder 4.8.3. Thanks for bearing with us!

When you empty the Trash via Path Finder 4.8.2 under Tiger, its helper application ctask crashes. You get several crash report windows popping up right away if your bug reporter is enabled and “Quit Path Finder” menu gets disabled as a side effect. You must force quit Path Finder when you want it to be quit. If you usually quit PF only upon system shutdown, you will get a “Path Finder cancelled shutdown” dialog because of the disabled “quit” menu. It doesn’t have any effect on the empty trash operation itself - it is done correctly every time.

The workaround

There’s no feasible workaround as such, except to stop emptying the Trash via Path Finder under Tiger. Disabling the bug reporter (Preferences -> General -> uncheck “Enable bug reporter”) will stop the crash reporter windows appearing right away after emptying the Trash, but you will still have them popping up at next PF startup and the “quit” menu will get grayed out. The bug is already fixed internally and we’re working at getting out this fix as soon as possible.

The story of the bug

It has been only two weeks since the moment that Leopard was released and we already started to feel the double-workload that is coming upon us, because testing and writing code for two different OS versions can be very difficult and error prone.

Internally we all switched to Leopard for our everyday use - I even made it a couple of months before the Leopard GM was out. So for Tiger testing, I should basically switch to my Tiger partition, look through the changelog and figure out which areas I should test. However switching to another partition and spending some time for testing is not the same thing as using the application 24/7 on your main user account. We still have a bunch of beta testers that use Path Finder on Tiger, maybe even the half of them, but it was unfortunately still not enough to uncover the problem described below.

At some point during Path Finder 4.8.2 development, Steve noticed a console message on Leopard that was pointing to a small internal problem in our helper application - ctask - it appeared to quit before the main application finished communicating with it. That was not correct, so Steve proceeded with fixing it and changed this:

- (oneway void)unsubscribeClient:(in bycopy NSNumber*)identifier;

into this:

- (void)unsubscribeClient:(in bycopy NSNumber*)identifier;

You see the difference is just in one word “oneway” which was removed (for technically inclined this works using Distributed Objects). The console message on Leopard disappeared and all was well. “Hopefully I didn’t break anything on Tiger” said Steve. Several beta builds went out to beta testing, I switched to Tiger several times, tested copy, move, delete - those are the operations that the helper tool is responsible for - also some other things, and it appeared to be ok. Hopefully.

Hours after the release of 4.8.2 a flood of ctask crashes on Tiger started to pour into our mailboxes. Unfortunately this one word change that fixed a tiny problem on Leopard introduced a crash under Tiger!

Thoughts

What did it teach us? We should try to test more on Tiger from now on. True. That means that every fix must be now tested twice - on Tiger and Leopard. And it already revealed itself as a difficult situation. We would prefer to be rock solid on one OS than slightly buggy on both. Just thinking aloud.

If you’re a developer, how do you organize the testing of your application on the previous OS version? Please share your experience in comments.

Taming the Leopard

It’s unfortunate timing that right at the moment of a major OS release when Mac developers need Apple engineers the most there’s no WWDC. This would make asking questions, talking with Apple, and demoing Mac OS X 10.5 issues much easier.

That said, it looks like the folks from Apple’s Developer Technical Support (aka DTS) are swamped at the moment by hungry third-party developers pummeling them with all sorts of Leopard-related questions. We’ve also contributed to that pile over the course of Leopard’s development and we’re not quite done with them for quite some time it seems :)

With the release of 4.8.2 we’ve fixed the most annoying Leopard compatibility issues. I mentioned some of them in my recent blog post and you can find the rest of the fixes in our changelog. However there are still some mildly annoying issues on Leopard that we were unable to fix and we’re waiting for Apple’s help.

• Moving items across partitions copies instead of moves - Normally when you copy a file across two partitions with the command key held down, it’s moved and the original is deleted. Unfortunately this is broken under OS X 10.5 and instead of moving the file, OS X copies it. This appears to be an OS Bug in system frameworks and we filled a bug with Apple. Hopefully it will be fixed soon in an upcoming OS update. This is annoying but since it fails in a ‘data safe’ manner, this is less critical. The workaround is to manually delete the source file upon the successful completion of the “move” operation.

• Path Finder’s desktop disappears when Expose is triggered - As I mentioned in my previous post, there’s no public API to “stick” Path Finder’s Desktop in place when hitting F11 and we still need to find a hack. My suggested workaround would be to make a Path Finder alias (File -> Make Alias -> Make Path Finder Alias) of the Desktop folder in the Dock, so that the Desktop folder is revealed in PF by clicking on the docked folder.

• When copying/deleting in List View it collapses subfolders - this seems to be an OS Bug in NSTreeController and we’re working with Apple to find a workaround or a fix. This is now fixed in Path Finder 4.8.3

• Network shares are missing from the Path Finder sidebar - On Tiger the system was finding the shares for us - there was a hidden /Network folder where all local shares were listed. On Leopard that is no longer the case. When we started to look for our own solutions, it turned out that public frameworks on Leopard allow third-party developers to find only Bonjour-based devices e.g. essentially Macs. Windows and Linux shares use another technology (NetBIOS) to broadcast their presence on the local network and we’re currently talking with Apple (yet again, thanks DTS folks :) ) to find a solution. In the meanwhile the workaround is to use the Connect to Server dialog.

If you notice any additional issues, please, report them to us so that we’re able to fix them in a future update. And while we’re working our asses off to fix the aforementioned issues, please enjoy new Leopard features: you can now QuickLook your documents from PF (just hit the Spacebar) and Reveal documents in Path Finder instead of Finder from your favorite third-party applications (check out the Preferences -> Reveal -> Set PF as the default file viewer).

Path Finder 4.8: known issues on Leopard

Now you probably got surprised when you’ve read this topic name, because we repeatedly told that Path Finder 4.8 is compatible with Leopard. For the most part it certainly is, but unfortunately the last Leopard seed reserved a couple of surprises for us that I thought you would like to know when planning your Leopard upgrade.

As I eluded alluded in my previous blog post on this topic, testing on an unfinished OS is a tricky business. I saw Path Finder bugs appear in one OS seed, disappear in the next couple of seeds, reappear in the fourth one and then disappear again. Generally if we saw a bug that persisted through more than two seeds, we proceeded with fixing it. Therefore you can understand why Mac developers are getting annoyed by the fact that Apple didn’t give us access to the Leopard Gold Master seed before the general release date - we have no idea if some of the issues below will still persist on the Leopard GM which is to be released on Friday. Here’s the current list of the known Path Finder 4.8 bugs on the pre-release Leopard build:

A folder popping up in the Dock while copying/moving/deleting files. Path Finder uses a helper tool called “ctask” to do its copy/move/delete operations - it launches and quits when the operation is complete. Somehow this background tool materialized in a form of a folder which behaves like an application popping up in the Dock when it launches. It doesn’t affect the quality of the copy at all - it is just kind of funny to watch. The history of this bug looks as following: fixed itself in build 9A343, reappeared in 9A466, fixed again in 9A527 and reappeared on the last seed. Now Steve’s bet that it disappears in the GM, and I’m still kind of nervous that it won’t.

Operations as root fail - this is a biggie that suddenly appeared on the last Leopard seed. The bug manifests itself as following: one operation as root is usually possible the first time upon installation of Path Finder, all further operations as root fail, also as a side effect - the “Quit” menu gets disabled when such operation was unsuccessful. After discovering the issue we immediately contacted Apple to ask what’s going on. It turned out that they implemented some additional restrictions for helper tools running as root to make the OS more secure. It is now considered unsafe to use any relative load paths in setuid helper programs. So the fix number one suggested by Apple -

-is to use absolute paths. Usually @executable_path is just used by apps that want to be drag installable. Apple typically ships an installer for software that requires setuid helpers, but we can understand the desire to maintain Path Finder as a drag-installable app.

Yes, we don’t really want to ship as an installer, because it seems that people generally don’t like them. Most of users prefer just to drag their app to the /Applications folder, because it seems more transparent and intuitive.

Another possibility to fix suggested by Apple would be

to replace your setuid helper tool with a daemon started by launchd. This is the direction we would like to see developers go and it’s a more secure approach.

Now this is also a bit problematic - the cool part of our helper tool is that it is not hanging around all the time. It quits and launches when needed. A daemon would always work in the background which is probably less desirable. However if we don’t have any other choice we will prefer this option. This requires some considerable work in restructuring our code and we still hope that there’s an easier solution. We’re still discussing this issue with Apple and will hopefully decide soon which road to take. This bug is highly unlikely to disappear by itself and we’re really sorry for the inconvenience that this issue might cause you.

When you reveal the PF Desktop in Expose - the Finder Desktop is shown instead. This is because we used an undocumented hack to make Path Finder desktop “stick” when hitting Expose, and it’s not surprising that this method got broken on Leopard. We hope we will find another hack soon :)

Issues with tooltips in Column View - when you hover over long file names in Column View, it should normally show you the full name in a tooltip, but it shows some weird numbers instead. This issue would be completely harmless if the Size Browser wouldn’t take it so badly - unfortunately it crashes because of this for some reason. Steve thinks that this issue will fix itself on the Leopard GM build, but I again remain skeptical. We placed bets yesterday - if he’s right I will have to send him a T-Shirt with “München” written on it :)

We hope to address those issues as soon as possible. We’re especially upset about the operations as root issue, since it has taken us by surprise and so late - we were testing Path Finder on Leopard since more than one year and if those OS restrictions were implemented earlier, we would have had more time to find a solution.

Update : looks like all issues mentioned above are still present on the GM build. The final build also brought some new bugs - issues with Connect to Server dialog, cosmetic issue with Desktop selection and a bug where “move to” contextual menu item copies files instead of moving them. We’re now intensively working on fixing all those issues as soon as possible in the next maintenance update. We’re sorry for the inconvenience.

Betas and testing

An interesting post by Steven Frank of Panic Software has recently started a discussion about difficulties of doing efficient software testing for Mac shareware programs. I found many similarities with our own testing workflow experience as we’re also “old school”, e.g. we’re doing our beta testing in a closed private group and almost never release something called “beta” to the public. Steven writes:

Having a couple hundred beta testers sign up, and only getting any feedback at all from maybe 10% of them is still a bit depressing and sometimes worrisome. It’s hard to know whether to interpret it as “people aren’t using the beta” or “there’s nothing wrong with the beta” or “I just signed up in the hope that I’d get a free copy” or “I had some weird stuff happen but didn’t think it was worth writing about”.

This is true to some extent concerning our own beta testing experience. However I discovered that a very important factor in receiving more feedback is to foster a sense of community among your beta testers. There are tons of posts written on “how to get more comments on your blog” or “how to make a successful forum”, and I think that this kind of tips apply to beta testing as well, since you basically get a small community of people united for the same task. So it all comes to the way you’re moderating this community. While Joel on Software already has some excellent tips on the topic, let me mention a few strategies that worked for us to improve beta testing feedback:

• Mailing list - my experience on our support forum shows that people like to communicate with each other about software issues. When one person reports something, the other one will add some details, etc. On our beta list we sometimes get very heated discussions about usability issues or feedback about UI changes, which are indeed very valuable and can’t happen if people don’t interact with each other. I think a mailing list is essential in building a passionate beta tester community.

• Listen and respond - be as present as possible. I try to respond to each filled bug and tell what happens next with this report, so that people know that we’re actively working on it. If not beta testers don’t know wether they should interpret the silence as “does it mean that the devs agree” , “does it mean they already knew about it”, etc. We don’t open our bug tracker to the testers, so our responses are the only mean for them to know about our progress.

• Fix what they tell ya - sounds obvious, but if people reported tons of stuff and the next build doesn’t contain those fixes, don’t be surprised by the silence. If for some reason it was impossible to fix, consider including it in the “known issues” seed note section.

• Regular builds - I think beta builds are still mini-releases, so same rules apply on a smaller scale - reasonably frequent builds show that we’re working on it and thus generate interest. Too much seeds make people tired and they stop downloading them. A way to know if seeds schedule is correct is to have some kind of a statistic following the number of beta downloads. This way you will be able to know if everyone downloaded a particular build or if you make builds too fast, and people started to skip them, etc. I think that a build per week is a reasonable timeframe, but your milage may vary.

• Comprehensive seed note - I think it should at least include following sections: a detailed changelog mentioning which bug of which tester got fixed in this build, a “known issues” section mentioning reported bugs that didn’t get fixed, focus areas - containing things that you think might be broken and you would like your testers to try out.

• Ask questions - People like being asked about their opinion. Also very few beta testers will write to the list just to say that this or that part of the software works. Asking them to confirm something will often “wake up” those who generally don’t write much. Asking a question is also a good way to initiate a discussion, which can uncover usability issues and opinions that people always hesitated to tell you about.

And if everything else fails, make a call for new people and refresh the list.

Of course the intensity of the feedback greatly depends on the way people use the software. Some programs are made to be used every day - and we fall in this category. Of course a program that is supposed to be used not often and only for specific tasks will probably have more trouble to get tested throughly in a short period of time.

I use the opportunity to thank all our beta testers for their continuos support. Our last beta cycles were very intense and beta feedback helped us a lot to have a stable and smooth release.

Did you participate in any beta testing? What makes you want to write feedback to the developer? Tell us about your experience.

Path Finder 4.8: making you more productive

We’re happy to announce that one of the most requested Path Finder features will at last make its appearance in the upcoming Path Finder 4.8: per-folder settings. The number of requests we received for this feature has been incredible. For an example, take a look at this thread from the Cocoatech forums — it dates back to 2003 and that’s only because the forum has been online since then!

Core Data

The implementation of per folder settings took over two months of work. To accomplish this we used a Cocoa technology introduced in Tiger called Core Data. Unlike the Finder (with its notorious .DS_Store files) we use no hidden files, we do not require files scattered around in every directory, and no helper files will ever silently appear on your network shares or external hard drives.

Path Finder 4.8 will store its visual per-folder settings in a centralized SQLite database located in ~/Library/Application Support/Path Finder/CoreData. Its size is very small - mine currently weighs just about 150 KB.

Core Data turned out to be really great for our needs, although Steve had to spend some time hacking away at it due to the fact that it only handles basic data types like numbers, strings and data. We had to add our own custom code to handle the unsupported objects like NSColor.

Cool, but what does it all mean for me?

Imagine the following: you can now have your Pictures folder in Icon View, with a special background and the info pane below the icon preview showing you image dimensions and sorted by date created. You can have your Home directory in List View with Documents and Desktop folder triangles always expanded. And you can browse the rest of your hard drive in Column View. Sounds great, isn’t it?

And the best part

This upgrade contains everything — it has an important UI overhaul, a major feature, and a ton of bug fixes and other improvements that would perfectly qualifies it as a major release. But we decided not to go down that road. We’re making it a free upgrade for all existing Path Finder 4 users!

Over the past 18 months Path Finder 4 customers have enjoyed some great updates for free, including:

• The transition to Intel / Universal Binary
• Undo support
• Operations as root
• Reload button
• Tabs enhancements
• Subversion plugin, and now -
• Per folder settings

We’re at the last stages of internal beta testing phase now, and if everything goes as planned, the update should be ready very soon. Stay tuned!

Path Finder 4.8: now with new duds

As Sasha alluded to in the previous post, we have lots of cool stuff coming soon for you to play with. I’d like to talk about a couple of them to give you an idea what we we have in store for you in the upcoming Path Finder update, version 4.8.

Depeche Mode

One of the trickiest things for OS X developers is designing how their application looks. Like or hate it, every time Apple releases a new version of OS X it’s like the designers at Fashion Week in Milan trotting out next season’s hot new looks. Will it be a new version of aqua? Will brushed metal get called back from the minors? Or will the spinning beach ball get a high fashion makeover?

From what I can tell there are least three major window styles in Mac OS X 10.4: aqua and the unified toolbar, brushed metal, and the newish “dark aqua” as seen in iTunes and the iLife applications. (Let us not talk about the weird wood panelling found in Garageband.) For the most part, though, there’s two major window styles: aqua and brushed metal.

Path Finder has historically straddle the divide between these two window styles by offering a preference to switch between either one, with a recent Path Finder update swapping in an approximation of the iLife dark aqua look for brushed metal.

In some ways this is great - the aqua lovers get all of their unified toolbar goodness and those who prefer the darker, more manly brushed metal / dark aqua look can have their macho and eat it too. This made things difficult for us, however, as we were constant tweaking and fussing with two separate but equal visual styles.

The Style Council

In Path Finder 4.8 this dual technicolor dream coat is no more. We are now introducing a new, single look for Path Finder based that closely follows the Mac OS X 10.5 window style. This means that we no longer have to split our efforts across two separate visual styles and as well Path Finder 4 users running Path Finder under either Tiger or Leopard will get the same visual experience.

Pictures speak louder than words, so here’s a couple of screenshots:

Here’s Path Finder 4.8 running under Mac OS X 10.4:

And here’s Path Finder 4.8 running under Mac OS X 10.5

Having a unified look means we can start really optimizing Path Finder from a visual standpoint. We know Path Finder is far from winning any interface beauty pageants and this is something we want to start addressing as we continue to refine and improve its interface.

There are no bands I can think of with the word “leopard” in their name

If you haven’t sussed this out by now, the fact that we’re showing Path Finder 4.8 running on Mac OS X 10.5 means that this upcoming Path Finder release is our first to officially be considered “Leopard (unless Apple changes something before the October release) compatible”. Things still may break when Apple finally gets OS X 10.5 into our grubby hands, but from what we can see we are Leopard ready.

So you get OS X 10.5 compatibility (with a caveat) and a brand-spanking new interface, and we’re just getting started. We’ll be posting more information about the upcoming Path Finder 4.8 release in the coming days, so check back for more details soon!

Excitement in the air…

Keywords:

adrenaline
caffeinated
excitement
secret feature
screenshots
leopard
last polish
soon

La, la, la...

Em... I'm also taking questions...

How we work

Did you ever wonder how we work? Do we sit in an office together? Em, no, we don't. Actually we can't. We're in three different countries! And even in three different time zones! That's crazy would you say, how can people work together if they don't even see each other face to face every day. Well, modern internet technologies nowadays make it perfectly possible for three people from US, Canada and Germany to form a company. And today I want to write about how my average work day looks like.

Morning rounds...

First thing I usually do is to look at the timeline in the bug tracker, to check what got fixed during the night when Steve was working (don't worry, he didn't work during the night, it was a day for him - we have 9 hours of time zone difference between us). And yet again some Steve's commit comments of fixed bugs are not understandable. Grrrr.... Looking at code, aha, that's that bug about wrong highlighting on desktop, number 234. Ok, closing that ticket. Entering it to the changelog page. (By the way, we use Trac for our bug tracking and we are really happy with it).

Now looking at emails. 15 emails from beta testers. Woohoo... Reading. Reading. Still reading. Ok, this one looks like a bug, needs testing, maybe reproducible. Marking that email as todo, will test that later today.

Now crashlogs. 15 new crash logs. Let's see. Already seen this one nn times, not fixable, sorting to OS Bugs. Next looks like this PDF crash again, tired of those. When will we be able to reproduce it at last? Maybe I'll try to play with that one more (like maybe 10th??) time today. No idea, maybe make a folder of 10 GBs of PDFs and try to open them all at once... Or try to open them one by one very very very quickly. Or preview them everywhere, in each drawer and all sections of the bottom pane. Or everything of the above at the same time, more weird it gets, the better... Maybe I'll luck out today who knows.

Ok, now forum. 3 new posts. Good, that's not much. Now when will they stop calling their topics "a couple of suggestions" or "desktop problem, please help", grrrrrrr... Needs renaming. This question was already asked 100 times, why won't he bother to enter it to the search box? ok, nevermind, merging with an older thread. Now answering. Done. Looking at the weblog comments. We get almost everything into the junked folder, so I need to sort out good comments regularly (if someone knows how to save me from this hassle, please, let me know, thanks). Probably there are no good comments, but I'm going to look through all this stupid junk stuff like "Hi, great site" or "buy cheap levitra", etc. ... actually what's levitra? I have no idea, might google that one day. Morning rounds finished. Going to read some fresh techie news and blogs and have my breakfast now.

And it was evening, er... morning, er...

It's late evening now - around 7 PM my time. Steve usually comes to the office about this time (10 AM in SF), but he's still not online. I know he's probably making coffee and checking his mail. He's going to fix something first, and when he has a sense of having accomplished something, he'll launch his iChat... After another session of desperate attempts to reproduce that PDF crash (no luck today either, sigh), I'm preparing my usual checklist of stuff to tell him about - beta testers opinions of the new Get Info window look, a couple of new common crashes just for the info - they are still not reproducible, and I should also remind him to send that TransitionTimer crash to DTS. We'd then usually video chat for about an hour or so discussing all that stuff, Steve would tell me what he's planning to work on that day, we decide what's important to look into next, etc. We then usually discover that we need to clarify a few things together - I will show him how to reproduce something he couldn't by himself or he would ask me to research some technical info for him, etc. And we end up working in parallel for a couple of hours, sometimes trying to solve same problem, or sometimes working on two different things. When Steve's going out to lunch - I'm usually going to sleep. He will then continue to work, and a couple of hours after he leaves the office, I'll wake up and begin my day. So we can proudly claim that Cocoatech is working round the clock for you :) .

Essentially my work consists of taking away issues that are not directly related to programming, so that Steve can have his head free from stuff that could slow down his coding. Besides that, we just have a lot of fun working together and we're very good friends. I hope that I could bring our developmenet process and atmosphere a bit nearer to you with this post. Do you happen to work with people in another country? What means of communication do you use? I would love to hear about your experience.

Path Finder and Leopard

We get a lot of questions regarding Path Finder and the upcoming Mac OS X 10.5, codenamed "Leopard". Will the new Leopard Finder make Path Finder obsolete? Is Path Finder compatible with Leopard? How well does Path Finder integrate with the new Leopard desktop? I will try to address those concerns and shed a bit more light on our development status regarding OS X 10.5.

We were glad to hear a lot of people coming back to us after the WWDC'07 Keynote with encouragements. Some folks were a bit anxious about Path Finder's future and it seems that the keynote calmed those fears. I have a feeling that this happens nearly each time when the next major OS release is near.

Peering into the future

Let us reveal something that is probably going to be surprising to you: We didn't really have any concerns about Path Finder's future. Why? Because we think that Finder and Path Finder are targeted to different types of audience. Finder is designed to be as minimalistic, self-explanatory and easy as possible. Something that your grandma can use without asking you twenty times where to click. Path Finder is designed with power users, administrators and geeks in mind. I personally see it like a Finder Pro version. Some features can (and should) overlap for sure, but initial design goals are so different at their roots, that the purpose and functionality of both programs will never really be same. Integrated Terminal, Console, ability to view invisible files, change permissions as root and other types of similar actions are clearly an overkill for an average Mac user that only wants to organize photos and documents in his home directory. The rest is just work. There's nothing impossible to implement, it's usually just a question of time and priorities.

We started to test Path Finder on Leopard immediately after WWDC 2006. Testing a programm on an unfinished OS is a tricky business. If you encounter a bug you can't know for sure if it's yours or it's in the OS and is going to disappear by itself in the next OS build. So each bug should be tested a second time on the following OS build to make sure it's worth fixing. Path Finder also uses several third-party frameworks, such as Omni frameworks, RBSplitView, etc. whose developers needed to do the same kind of work as well. This work is still in progress, but Path Finder 4.7 has come a long way and only minor Leopard bugs remain as of now (and again we should see if it's still reproducible on the latest OS build :) ).

So, how well does it actually work?

Ok, ok, a bit more juicy details now. Path Finder's Desktop is correctly displayed in all Spaces, clicking on files on it will bring PF's browser window as usual. There's no problems with Stacks - PF and Stacks don't interact that much in fact. You can drag and drop items from and to Stacks as you would do with any other program. The only thing is that Stacks have a "Reveal in Finder" button, but I don't think it will be used all that often. Concerning Time Machine, it is based on an underlying OS technology that Path Finder will be able to leverage as well as Finder already does. Time Machine doesn't rely on Finder to know what and when has changed (it's actually rather vice a versa), so there's no concerns about this, it should work without any problems if you leave Finder running and use PF as your main browser.

You've probably heard a zillion times by now that Leopard has a lot of cool technologies, like Core Animation, that developers can use. We're of course very excited to adopt those technologies. It requires some work however. First you need to learn how to use it, then you need to adapt your code to the changes, make architectural decisions, etc. It's also a good time to clean, pretty up, and rewrite bits of our own code.

As for the new upcoming features, really, that's the most easy and fun part of all. When the code is all shiny, new and cool, major bugs are kind of ironed out, adding new features becomes the most exciting part of the development process. So rest assured that we're as much excited about the upcoming release of Leopard as you are, we just need to do our homework first :) And then we're going to have some real fun that we hope you're going to profit from as well :)

And now I'm going back to explaining my mom how to print (her recent question: and who's pushing that big gray "print" button on the printer itself then?? how come computer? when? OMG!). I would never install Path Finder on her account, sigh :)

Bonus: here's how Path Finder looks like on the latest Leopard's build:

Some interesting stats

I love statistics. Making charts and spreadsheets is sort of my kind of thing. It makes everything look clear and often it allows me to discover new things and gather new insights. In Path Finder 4.7 we integrated a very cool tool to gather some information about our users, it is called Sparkle Plus framework. It sends us your system profile information, such as amount of RAM, processor speed, language that you use, Path Finder version, OS version, etc, and does so anonymously. I thought that sharing this information could be interesting and probably potentially useful to some other developers over there, since we probably all share a similar user base. So here we go.

First about your computers. It looks like majority of you are using new fast machines with the latest version of the OS.

> 60% are running on Intel processors

> 70% appear to have more than 2 GB of RAM installed.

> 80% upgraded to latest OS Version - 10.4.10 - within the first week of it's release

MacBook Pro is the most popular model, followed by various PowerPC desktops as shown on the chart below:

As you maybe know, Path Finder is localized in 17 languages, thanks to enthusiastic volunteers that agreed to help us with translations. Now here's how those translations are actually used:

The "Other" part looks like this:

Now we're not the first to gather this kind of information. Omni group was doing this since a long time, and their charts seem to have a lot of similarity with ours, which is not surprising. Mac developers have the chance to code for technically aware audience, which upgrades to the latest and greatest as soon as it becomes available. As far as I know, this is far from being true on other platforms, however I don't have any statistics to prove that :) .

Now I'm really feeling myself behind the masses with my faithful PowerBook '12 with "only" 1 GB of RAM which I'm writing this post on. But I really love it - it's small and elegant, I can take it everywhere and I will really miss it, if nothing of the kind and size will be released in the near future.

Path Finder SDK

I just posted the new Path Finder 4.7.1 today along with the new Path Finder SDK.

It took months of development time to create the simplest possible way of creating plugins for Path Finder, and I've converted much of my own code to run as a plugin. I'm "eating my own dog food" as the saying goes.

If you know Cocoa, please take a look and email us if you have questions. I included lots of sample code which are real world plugins, not half baked "hello world" plugins. These are the same plugins shipping with Path Finder. If you write a good plugins, I'll gladly ship it in the official release. I also plan on hosting your plugins on my server if we get lots of developers writing cool plugins.

Take a look at the tutorials and try improving the samples. The SDK is part of the Path Finder download DMG so look for it in there.

I'll post more info later, but there's plenty of info to get started.

Path Finder meets Subversion

We listened to your numerous requests and we're glad to offer you our brand new Subversion client in Path Finder 4.7.

If you never used Subversion, you should try it out. Basically it's like Time Machine without those cool flying windows on a stars background :) (mmm, it's the other way round actually - Time Machine is like Subversion, but nevermind) Versionning systems like CVS and later Subversion were used by programmers since decades to be able to go back in time and revert to an earlier state in case they broke something. And yes, this happens. It even happened during our work on this Path Finder release. Steve updated to the new iTerm and made lots of custom changes to the code. At some point we noticed an annoying flickering when scrolling in terminal which was not present in iTerm itself. It was clear that Steve introduced this bug himself, but the quantity of the changes was so significant at that point that it was impossible to remember where and when it happened. Subversion came to rescue - first we reverted the code to the state it was two months before that, it worked fine. Then we took the revision of last month - it was broken. Then we went two weeks back from there, it still worked. And so on. At the end in less than one hour (of which most of the time was spent recompiling) we were able to isolate one line of code that introduced the bug. And that was very cool! :) You can find more about Subversion here and find the installer package here.

SPOD? No thanks...

A lot of questions arose when we started to brainstorm about this feature. There is a bunch of Subversion clients out there, but somehow most of the people I know end up going back to Terminal for one or another reason. Maybe because it's quick and simple, not sure. So we wanted to come up with something very simple and fast, yet sufficient for every day use. Something that we would use ourselves instead of Terminal actually :) So the first concern was speed, we wanted to avoid at any price that the whole browser beachballs and stalls when polling for svn updates and that's what could happen if we tried to show svn status directly inside the browser for example. So we decided to make a separate, independent section in the bottom preview pane which only asks the browser which folder is currently selected and then does it's job without disturbing any other actions you might be executing in the browser.

Subversion client for the rest of us...

Using Subversion in Path Finder is pretty straightforward. You don't need to do any setup if you already have a repository and Subversion is installed on your computer. Select your working copy in the browser or in the shelf and open the subversion pane (select it from a list in the bottom pane) or window (Window -> SVN Window). Now you have a set of commands that you can use immediately. Some of them will require additional input of arguments, in this case there will be a panel popping up where you'll be able to enter them. If you want to use a command that is not listed, no problem - click on "Other" and type your command (without word "svn") with any arguments you want just like you would do in Terminal (actually it just launches a shell in the background and executes it exactly as if you would type it in Terminal). We used "raw" command for debugging - to see all the output that svn generates without formatting. We decided to leave it there in case you would like to see what's Path Finder doing exactly and in case we need to see what's happening if you encounter problems.

We warmly welcome your feedback about this feature. Please let us know what you like and what you hate about it. We're listening :)

Path Finder Quickies

Did you know that...

... you can prevent your important files being accidentally changed or deleted by "locking" them? Select your file, go to Permissions tab of the Get Info window and check "Locked" - and voila! If you want to change or delete this file afterwards, just uncheck it again.(This feature will only work on HFS volumes).





... you can automatically resize the column to the width of the longest file name in Column View? Just double-click two bars located at the bottom of the column separators:







... you can print out your files in a nice list? Of course you can simply choose "Print" from File menu, but it will print the whole browser interface with it. There's a better way - go to File -> Reports -> Directory Listing. It will then generate a list of files in the currently selected directory in four different formats - with icons, without icons, full path, URL path - and open it up for you in the built-in text editor. (While you're at it, check out other reports, like "Man to PDF" that allows you to look at - and also print and search - that lengthy man page).





... you can batch rename files with an Automator workflow? Courtesy of Philippe Martin, developer and Apple Script guru, you can find complete instructions here.

Aliases, symbolic links, Path Finder aliases… Help!

Today I want to write about something that confused me once and I was glad to find the explanation afterwards. I hope it will be useful for you as well. So here we go about the difference between aliases, symbolic links and Path Finder aliases.

Look similar...

Aliases and symbolic links (or symlinks) are "pointers" to a file or a folder which can be placed at a specific location while it is pointing to the "original" object at another location. You basically create a second representation of the object without having to create a copy.

Aliases are files that uniquely point to a specific file or directory, and continue to point to it regardless of where the file or directory (or the alias file itself) is moved or renamed. When an alias doesn't resolve, the system goes looking for it and asks you what it should do if it can't find it. Aliases are understood by the Finder, Path Finder and any other OS X program that implements the routines to resolve aliases.

Symbolic links are very similar to aliases, but symbolic links are lower level. They belong to the file system itself, and thus can be parsed by your terminal shell. Most Unix-level commands and utilities do not understand aliases, so it is necessary to use symbolic links if the file or folder will be accessed from a Unix-level program (e.g. Apache). Programs of higher level, like Finder or Path Finder have no problems to resolve symbolic links, so symlinks are understood throughout the whole system.

...but are different

An important difference between an alias and a symlink is that if the original file is moved or renamed and a file with the same name is put at the former place, an alias will still point to the previous version of the file, while a symbolic link will point to the new file at the same place. This behavior is useful e.g. when you need a reference to a file or a folder which is replaced in regular intervals by new versions, while the previous versions are archived. However a disadvantage of a symlink is that when it doesn't resolve it just goes broken. (it happens because symlinks are just files containing a string with the path to the file, whereas aliases store their information in resource fork thus containing more information about the original)

Both symbolic links and aliases are useful. Sometimes you want to point to a particular file or directory in a robust manner that will not break when things are moved or renamed (alias), but sometimes you simply want to point to "whatever file happens to be located at the following path..." (symlink). So the decision to use one or another depends on what you want to do with your original and what programs are supposed to access the link.

Although symbolic links are a core feature of Mac OS X, Finder is unable to create them. Also there is no easy way to distinguish an alias from a symbolic link in Finder. Both aliases and symbolic links appear in Finder with a little arrow in their icons. If you use "Get Info" in Finder on a symbolic link, it will show its kind as "Alias" - which is a bit misleading at least. Path Finder knows how to distinguish between symlinks and aliases, displaying their kind correctly and can also create them sparing you a trip to terminal.

Now what are Path Finder aliases?

Path Finder aliases are like regular aliases but that only Path Finder understands. They will always open the original in Path Finder regardless of the program you use to open them. They are actually just special files (with a hidden extension .path) that PF knows how to open, their kind is "Path Finder document".

What are they useful for?

Suppose you would like to have a folder in the Dock which would open in Path Finder. You can create a Path Finder alias (go to menu File -> Make Path Finder alias) of this folder and put it in the Dock - it will then always open in Path Finder instead of Finder. Handy, huh?

---------

Update: one of the commenters reminded me about hard links and I thought I'll complete my explanation although hard links are only rarely used on OS X.

Hard links - beasts from the past

Hard links act like "twins" in sync, you can't even tell which is the link and which is the original actually (Get Info on both files will show exactly same type of document, same size, etc). For example you change permissions on one file - and it automatically changes it on the other one, you can't even delete the file completely without deleting the other. On OS X Tiger it's not possible to make a hard link to a directory, only to a file (update: this is no longer true on Leopard, Time Machine uses hard links to folders), also your hard link should be located on the same partition of your drive as the original.

As far as I know, hard links are not always well supported by high level OS X apps, probably because in a certain way they are even lower level than symbolic links. If you allow me to go to really low level details, hard links are direct "pointers" to a unique identifier - a file system object called "inode" - which describes where all the pieces of a file are as well as various other attributes such as last access, modified and create times. When the file is written to the disk, blocks of data containing the file are given this unique identifier (inode) so that your filesystem knows that "file #000234" is the data starting at disk block #00FF and ending at ##0145. Now consider the following: aliases store the path *and* this unique identifier in their resource fork (thus knowing about the physical location of the original on disk regardless of it's path and vice a versa), symlinks store only the path to the file and hard links store only the unique identifier, thus all those differences in their behaviour. To add some history (and I'll stop there, it's getting terribly long now) - hard links have been around since the earliest days of Unix, symbolic links were invented by BSD engineers somewhat later and aliases come from OS Classic.

Crash logs hunt

When Path Finder crashes an automatic crash reporter pops up asking you to send the crash log to us. You might wonder where are all those crash logs actually getting sent and why is it important to send them? Who looks at them and what does this weird text output that you send mean anyway?

Well, that's my job. First let me present myself a bit - my name is Alexandra, I'm doing testing, forum support, manage the bug tracker at Cocoatech, and a part of my job is to look at crash logs every day, sorting them out and organizing them in a database. How am I doing it? Glad you asked :)

First a bit of technical voodoo. Understanding crash logs is actually rather simple. At the moment the program crashes, it was executing something, typically in several threads (means it was doing several tasks simultaneously). One of the threads was executing what you were actually doing just before the crash occurred and ran into problems. This thread is then marked as "crashed". That's where I'm looking.

First I try to determine if I've already seen a similar crash in other crash logs - if I have a feeling that I have, I run a spotlight search on my database and see how many identical crashing threads I have. If it turns out that there are many - clearly we've got a problem. If I didn't find that it's a common crash - I look at the comment you wrote, this gives me an additional clue of what might have happened. If you wrote a comment, but the stack remains mysterious - I put the crash log in an appropriate folder - for example crashes that happened while moving files - in one folder, crashes on renaming - in another one, etc. So when I see that people get a lot of crashes while doing one particular task, even if the crashing thread of those crashes is not the same, something's definitely wrong.

Now comes the question - is it crashing in our code or somewhere else? This is also rather easy to see. If you look at the crash log above, you can notice that the left part of the output contains names like this: com.apple.CoreFoundation, com.cocoatech.cocoatechAppKit, lemkesoft.GraphicConverterCMI and so on. These are unique identifiers of applications, frameworks, but also input managers, contextual menu plugins and so forth. The execution of a thread, as displayed in a crash log, goes from bottom to the top - i.e. the last function that was executed appears on top. Typically "bad guys" are somewhere in the middle - the program is able to continue somewhat, but rapidly gets to an undesirable state, not being able to find what it expects and thus crashes. For example in the crash log above the Graphic Converter contextual menu was very likely the reason of that crash. This way I can sometimes clearly identify a third party contextual menu plugin or an input manager / haxie as being the problem and in this case I usually email the person back, telling her about that. If a third party plugin or an input manager causes Path Finder to crash often, I email the developer of the plugin in question. However the percentage of those crashes remains minimal. Lots of crashes are mysterious beasts not identifiable by any race or kind, living in an obscure forest of... eh, now my inspiration suddenly ended when it just started to be thrilling :)

Ok, so that's when you won't hear anything from me - a lot of crash logs just don't show any useful info. That means that the crashed thread showed only system frameworks or only a couple of system methods, etc. Those crashes can reveal OS bugs though, that's why Apple crash reporter comes up when every program crashes and not only an Apple-one. Since all programs rely on Apple's system frameworks, they also would like to know if a lot of third-party programs crash in a particular part of a system framework for example.

Now how does it actually help us? Consider the following situation: back in December just after release of Path Finder 4.6, I suddenly started getting an abnormal quantity of crash logs, all containing the same stack that showed problems loading Stuffit contextual menu plugin. After some investigation, it rapidly turned out that built-in Stuffit 11.0.1 was incompatible with the contextual menu of previous versions of Stuffit that people happened to have installed on their systems. We were able to fix the problem quickly, releasing a 4.6.1 emergency update just in 5 days following 4.6 release. Without the automatic crash reporter the problem would have taken a lot more time to identify. Not all common crashes are fixable in such an easy way though. Why would you ask? If you see that your program crashes in a particular function, you can just go to that part of code, see the problem and fix it, right? Unfortunately, it's only rarely the case. Most crashes are just like indices on the place of crime, they help, but if you will be able to find the cause depends on many things, the most valuable being the ability to reproduce the crash.

So, please, do send every crash to developers *and* to Apple with a short comment describing what you were doing when the crash happened (and pleeaase no "just woke up" or "having lunch" :) ) . You will help to make the developer world a happier place!

Path Finder profiled on MacBreak

I just noticed that Path Finder was recently demoed on Leo Laporte’s MacBreak show by productivity maven Merlin Mann. Those of you who are obsessed with productivity and Getting Things Done undoubtedly know Merlin from his killer 43Folders.com web site.

Yes, the Woz is a Path Finder user!

Merlin has been a long-time Path Finder fan (as has Leo Laporte) and it rocks that they’ve put together this demo. Their comments about Steve “The Woz” Wozniak also being a fan of Path Finder are true — I think I almost wet my pants in a nerd worship-induced spasm of delight when I saw his order go by a while ago.

A quick correction and a clarification

One thing that I should correct that Merlin mentions in the demo is that Path Finder installs a crash reporter — we did for a short while when Path Finder 4.0 was first released but this was removed and we now have an integrated crash reporting system that doesn’t install any extra doodads.

Leo is absolutely correct when he mentions that Path Finder is “just an application” — it installs no Input Managers, no haxies, no kernel extensions, or any other system-altering items. It’s just a plain old bundle application like Safari or Mail or iTunes, so there’s no chance of it affecting system stability or the stability of other applications.

Stuffit Engine

That said, because Path Finder integrates the latest Stuffit Engine in order to provide its compression and expansion features there are known conflicts with older versions of Stuffit products. We recommend if you’re running Path Finder full-time that you should uninstall any previous versions of Stuffit Expander or Stuffit Deluxe to avoid any potential issues.

It looks like we have a lot of new customers discovering Path Finder for the first time thanks to numerous mentions on Merlin’s web site and Leo Laporte’s MacBreak, so hats off to them for sending us some video podcast loving.

» Check out Path Finder on the MacBreak video podcast.

Speaking a good old-fashioned lovefest I’d like to send all of our amazing customers best wishes for 2007 (henceforth known as “The Year of Bond, James Bond”) from myself, Steve, Miho, and Alexandra. You all helped make 2006 our best year ever and we look forward to working with you this year to make Path Finder even better. Thanks!

Knox + Path Finder bundle offer ends October 10th!

As the saying goes, all good things must come to an end, and with those words in mind we note that the popular Knox + Path Finder bundle is soon coming to an end: October 10th, to be accurate.

For those of you who haven’t heard about the bundle deal, it’s a dandy: Get Knox and Path Finder together for the low price of $46.95. Enter PATHFINDER when purchasing from within Knox and you will automatically receive a license for both applications by email.

So be sure to purchase by 10/10 if you want to take advantage of this great bundle deal.

Crashing issues on certain Mac Pros

For those of you lucky enough to own one of the spiffy new Apple Mac Pro machines, I glower with jealousy in your general direction. That said, there is an issue with Path Finder on some of the new Mac Pro machines where Path Finder crashes on launch.

We’ve reported this issue to Apple and they have confirmed that there is a bug in the installed version of OS X that some of the Mac Pro machines ship with. They have informed us that they will be fixing this issue in a future OS update (the fabled 10.4.8, perchance?)

Interestingly, there are two different builds of OS X 10.4.7 that ship with the Mac Pros, and only one of them is susceptible to this problem.

To see what build of OS X 10.4.7 your Mac Pro is running, go under the Apple menu to About This Mac. After the About This Mac window has appeared, click on the version number that appears directly under the Apple logo. The version number will change to the OS X build number.

Any Mac Pro that is running Mac OS X 10.4.7 build 8K1079 will have issues getting Path Finder to successfully launch.

Steve received his Mac Pro a few days ago and we were surprised that Path Finder ran with no issues on his system. It turns out his version of Mac OS X 10.4.7 is build 8K1124 - a higher build number than the aforementioned 8K1079 build that doesn’t play well with Path Finder.

Until Apple releases an update that fixes this issue there is a work around that will allow you to launch and use Path Finder. Unfortunately it means losing the ability to compress files. :(

Here’s how to work around the crashing issue:

1. Select the Path Finder application in the Finder.
2. Right (or control)-click on it and select “Show Package Contents”
3. Navigate in the Path Finder bundle to:

   Path Finder.app/Contents/Frameworks/StuffitCore.framework/Versions/A/Plug-Ins/

   And move all of the contents of the Plug-Ins directory out to another location on your hard drive. This will allow Path Finder to launch.

We apologize for any inconvenience this problem may have caused and we hope that Apple gets the fix out for this quickly. If you have any other questions or comments, please post them in the Cocoatech Forum or send us a support email.

Path Finder 4 reviewed in MacFormat UK (4 out of 5)

I just noticed a few days ago that MacFormat UK magazine reviewed Path Finder, and gave it a positive review and 4 out of 5 stars:

"An excellent, affordable, feature-packed tool that's perfect for anyone who craves more power than Finder [sic] offers."

Thanks, MacFormat UK! (P.S. Path Finder 4.1 introduced read support for smart folders, and creating smart folders from within Path Finder is on our to-do list.)

Check out the review (warning - huge image):

Bob “Dr. Mac” LeVitus loves Path Finder

Bob “Dr. Mac” LeVitus was recently introduced to Path Finder by Leo Laporte (during the recent MacMania IV cruise) and we were happy to hear that he rather enjoys it:

It rocks. In a nutshell, Path Finder 4 is what the Mac OS X Finder would be like if I designed it. First and foremost it’s a file browser and manager like the Finder, but it also offers a number of innovative and powerful tools that make it ever so much more useful than the Mac OS X Finder. Even if you think you’re perfectly satisfied with the Mac OS X Finder, I urge you to read the rest of this column and see what you’re missing.

I think that deserves a hearty “woot!” Check out Bob’s full write up, and while you’re at it you can take a look at the entire list of applications that he, Leo, and the way-too-cool Steve Wozniak spotlighted as worthy.

Two Killer Development Tools

I live in XCode and it’s incredible, but there are two other development tools that I use regularly which have become indispensable.

The first is “Accessorizer”

Written by Kevin Callahan, this app literally changed the way I wrote code, and saves me hours per day. I use to be lazy about writing clean accessor methods. Not any more! Accessorizer takes care of all the mindless typing, and ensures that I don’t make any typo’s. The biggest source of memory leaks is sloppy handling of member variables. Accessorizer makes sure you don’t make mistakes. I would surely have had a terminal case of carpal-tunnel syndrome by now if it weren’t for Accessorizer.

The second tool is “OmniObjectMeter”.

I’m a new user of this app. I just discovered they have a beta that works on 10.4. I alway figured that ObjectAlloc was good enough, but I was wrong. OmniObjectMeter makes it so simple. Finding leaks is still time consuming, but it’s the best tool for tracking down each alloc, release and autorelease. 4.0.2 will be released shortly with a few memory leaks plugged. Thank you Omni!

Path Finder Universal build (soon)

Path Finder will be built as a Universal binary soon. I’m still waiting for the Stuffit Engine to become universal, and then it should be a simple recompile.

Stay tuned for more info.

• Steve

Path Finder 4: One week later

It’s been a week since we released Path Finder 4 to the world. Where does the time go? Now that the dust has settled a bit, I thought it might be of interest to post a bit of a look back at the last seven days, and a quick look forward to what’s in store.

A thousand merci beaucoups

First of all, thank you so much to all of our beta testers, customers, and everyone who has sent us comments, feedback (good and bad), and congratulations this week. Pardon the cliché, but the response really has been completely overwhelming and exceeded even our wildest hopes.

Here’s some of the awesome press that we’ve been lucky enough to receive:

• Productivity maven Merlin Mann at 43 Folders gives Path Finder 4 his “official okey dokey” and calls it “one badass Finder replacement that power-users will find pretty foxy”. He then went on to fill everyone in on seven things he liked about Path Finder. Thanks, Merlin!
• Michael Tsai (editor of the swank Mac magazine About This Particular Macintosh and creator of some mighty fine Mac OS X appications said that Path Finder 4 was “well worth the wait”.
• CreativeMac calls Path Finder 4 a “must buy” and says that “if you use a Mac, you need to be using Path Finder 4. Period.” Yowza!

Last Saturday night was filled with answering emails, monitoring the forums, and making sure the web server was up and running. I think I slept maybe a couple of hours. We had Slashdot-levels of traffic for most of Saturday night and throughout Sunday, and at peak there were over 300 people downloading Path Finder simultaneously. Luckily, though some elite nerdly mumbo-jumbo I managed to keep the server up and running (except for just at the start, sorry!).

Some vaguely interesting stats:

• Nearly 11,000 downloads as of this writing
• Peak simulatenous downloads: 312 on Saturday at around 7PM EST
• Over 2,500 emails received (and an equal number of responses sent out)
• Over 700 upgrades given away to eligible users
• 400 new forum members
• 8 (the number of cups of espresso I drank on Saturday night)

Updates are a-comin’

As hard as we try to avoid them, bugs can sneak in and Path Finder 4.0 is no exception. We made sure to test Path Finder extensively but with such a major code rewrite there were bound to be things that we and our alpha and beta testing groups missed. The good news is that our first maintenance release is already being put through its paces and we should have it in your hands in the very near future.

Besides fixing our #2 crasher (the bug where if you change shelves it can crash Path Finder), this maintenance release will have a number of smaller (but still important) issues fixed. As usual we will post a complete changelog when we release.

Our #1 reported issue right now is a crash caused by the new visual effects in Path Finder. It turns out that we may have stumbled across a Cocoa bug and Steve is working with Apple to try and track down the root cause. If you experience any beachballs or crashes when dragging and dropping items, check the “Disable superfluous visual effects” preference. This should work around the problem.

Path Finder is a constant work in progress, and you help us make it work better. We make an effort to read every email, forum thread, weblog post, and hastily scrawled note on the back of a cocktail napkin and we’re listening. If there’s something you wish worked differently, better, or something that you think is missing, get in touch with us.

If you’re looking for more information on features, bug information, and other useful tidbits, check out the forums.

UB, UB - do (with apologies to Frank Sinatra)

Okay, that was incredibly lame. Anyway, one of the questions we’ve been getting a lot is “what’s going on with Path Finder and its status as a Universal Binary?” The good news is that we’re waiting on one last framework to go UB and then we will be releasing a Universal Binary of Path Finder. And yes, it will be a free upgrade to existing Path Finder 4 users.

So all of you bleeding edge, early-adopter lucky-pants-wearing folks that have brand new iMac Core Duo machines or MacBook Pro laptops on the way will soon have a native version of Path Finder to play with.

Getting the most out of Path Finder

Over the coming weeks I plan to post quite a bit more here on tips, how-to’s, and getting the most out of Path Finder. I’m also taking questions, so if you have anything you’d like me to talk about with regards to Path Finder, get in touch.

Thanks once again to everyone for sticking with us, sending us your feedback, comments, and criticisms, and continuing to support us and independent Mac OS X software. We appreciate it all and know that we couldn’t do it without you Pat yourself on the back and buy yourself a big latté / coke / juice / beer / tasty beverage on us.

We have lots of cool stuff planned for Path Finder, so keep checking back and keep sending us your thoughts. Thanks, everyone!

Neil

Path Finder 4 is coming…

Path Finder 4 is done and will be released in a few days. I apologize that it took so long to finish. I got a little too ambitious and bit off more than I could chew. But, it's finally done and I think you will be happy with the results. Watch the site, it should be posted in a few more days. Just doing the final testing now.

I've also been working on a very cool integrated software purchasing system that's built right in to Path Finder. It's amazing! The back end is hosted on two dual XServes! I spared no expense to create the ultimate all Macintosh based purchasing system. The machines are hosted in a colo in downtown Los Angeles with an extremely fast connection.

Here's a picture!

It's been a long difficult journey to finally get Path Finder done. I promise frequent updates from here on out. I learned my lesson well, and plan to release lots of free updates in the coming year.

Thanks!!

Steve Gehrman

Cocoatech Update

Lots of great things have happened since the last major release of Path Finder, and I wanted to let everyone know that Path Finder version 4 is almost ready for release. This blog has been pretty stagnant for the past few months. Here’s why:

First of all, my wife Miho and I had a baby boy in November! His name is Kai Chet Gehrman. Kai means “Ocean” in Japanese, and Chet is my Grandfather’s name.

Here’s a link to my .mac homepage. There are lots of pictures and a few short movies. There’s also lots of family pictures.

I’ve been really busy during the pregnancy and after the birth, but I’ve been working like a mad man to get Path Finder 4 released. My daily schedule now is wake up at 2pm and work until 5am. I have found that I’m more creative and focused during those hours.

Another big change new since the last release is I have moved from working out of my apartment to working in an office. Working from home was good for a few years, but I eventually found it hard to focus, and with a baby, it makes it that much harder.

My office is located in beautiful downtown Santa Monica, California. It’s hard to imagine a better place to be. The weather is always amazing, the air is crisp and fresh, and I’m within walking distance to the Apple store on third street promenade!

My office address is: 1238 7th St. Santa Monica, CA 90401

If your in LA, or just visiting, stop by and we can go out for coffee. I’m always looking for an excuse to get out.

Path Finder 4 is a huge rewrite of most of the core code, and the UI is much better. I was a little too ambitious, so it’s taking some time to get everything back together, but I’m sure you will be happy with the vast number of improvements. Lots of Tiger improvements are in the works too, but I’m going to release a Panther version first, followed by a free update with Tiger enhancements. Please be patient, I know your going to love this new version.

More info coming soon!

Steve Gehrman

Path Finder 3.2 Beta - Soon

I'm working hard on the next release of Path Finder. I'll have a beta in a week or so. Adding more new stuff and refining the code. New Find/Find By Content window, CD Burning and other cool stuff.

Stay tuned and watch the web site. I'm going to have a public beta, so get ready to help test.

-steve

Path Finder Beta

I'm releasing a Path Finder beta in a few days. Email me if you want to be on the beta list.

I'm going to Japan next month, so I'm trying to release before then. The next release won't have all the features that people have been requesting, but I wanted to get something out before I leave.

If you live in Japan, let me know and we can meet up in Tokyo!

Graphics Professionals:

Requesting CocoaTech designs for t-shirts, sweatshirts, baseball caps/golf visors, etc.

Please email me your graphics. I'm going to start offering T-Shirt and stuff using www.cafepress.com so I need graphics.

Anything is fine. It doesn't have to look corporate or professional. It's just got to look good on a T-Shirt.

Need help localizing Path Finder

If anyone wants to help with localizing Path Finder, please send me an email.

Not all of Path Finders localizations are complete, if you notice strings that are still in English, please send me the translations in the form of:

"English sentence" = "Localized sentence";

I've give you credit in the about box.

Progress Report on Path Finder

Added a preference for using relative dates in the list view (today, yesterday, tomorrow).

Researching speed improvements. Nothing to report yet, but hopefully I'll get things faster

Added 10 and 13 point icons choices. (Previously 16 was the smallest icon size)

Added icons to alias files to match the original

Fixed a crashing bug when opening and closing a browser quickly

fixed a problem when double clicking in icon view and having the open panel come up.

Added a choice to View Text in addition to View Hex when a file can't be opened.

The date string will change depending on the width of the date column in list view. (1/31/69, Jan 31, 1969 3:30am, Thursday, Janary 31, 1969 3:30am)

I'm working on movable icons on the desk top now.

Path Finder Review

Check out the Path Finder review at www.Hubblemac.com

Really detailed and well written.

Thanks Hubblemac!

Thanks for your emails!

Thanks to everyone who sent in suggestions in the past 48 hours. My mailbox is stuffed, and it's going to take me a while to sort though it all. If you sent in a suggestion, and you don't see it implemented in the next version or two, just send it in again.

I can only program so fast, and I usually add features based on how many requests I received.

The support line has also been busy. We try our best to make sure that every email is responded to and everyone is happy. If for some reason you send a support email and you don't get a response, just email it again. We do our best, but sometimes an email or two can slip through the cracks.

Thanks for your support. I'm already working on 2.1.1.

I'll post more about 2.1.1 progress in a day or two.