Welcome back to our homebrew series about the future ForkLift 2.0. Admittedly, there has been a short hiatus in the series, I will be discussing this later on, but first things first:
ForkLift 2.0 will be 64-bit, and Snow Leopard only.
I know from experience that announcements of this sort often fail to provoke the merry cries we normally expect.
So, just say it out loud a couple of times and let the warmth of the promise of a bright future wash over you. Because I know some questions inevitably pop up: What’s gonna happen to PPC users? Screw that, what’s gonna happen to Leopard users?
Well, first, stay calm, there’s no immediate threat. This is an early warning, ForkLift 2.0 is still a good way away. In fact, we don’t expect a beta before first quarter of 2010.
Second, we’ve had this same dilemma when moving from Tiger to Leopard, and speaking from experience, that all came out well in the end. Most people simply switched to Leopard sooner or later (rather sooner), and the few people who still use ForkLift 1.2 to this day seem pretty happy with the software they have. Also, let’s face it, the last PPC models were sold in 2006, about the time BinaryNights started out.
That said, let’s look at the upside.
Obviously, 64-bit is the way to go. I’ve always abhorred the though of being limited to 4294967295 of anything on my computers. Also, we like the efficiency of the 64-bit architecture. Efficiency is good. Grand Central Dispatch and easier handling of multithreaded code, both new tools in SL, are also great, although BinaryNights is one of those developer workshops where multithreaded programming was never a challenge, so some of these new features will not affect ForkLift so much.
What does affect ForkLift a great deal is the new set of system APIs that shipped with Snow Leopard. I’ll explain.
About 6 months ago, we decided that the time was ripe for some radical programming. ForkLift 1.x was having its 2nd birthday, and the first bits of code we wrote were over 3 years old. At that point, we felt we had enough experience to write a REALLY good file manager.
Thus we started working on ForkLift 2.0, basically from scratch.
By the time we’ve set up the general framework, Snow Leopard was released to developers, and we were faced with radical changes in our working environment, namely the system APIs through which ForkLift interacts with OS X.
In fact, our current problems with ForkLift 1.7.5 in handling AFP shares is related to the arrival of this new API set -or rather, the discontinued support for older APIs. The past 2 months of patching up ForkLift 1.7.x. to make it run on Snow Leopard gave us a very nice excursion into the realms of this new API set, and also made it clear that this is indeed a brand new horse we need to ride. We all know that riding both horses -the new and the old API sets- can only lead to half-assed solutions, and indeed, we feel sadness at the sight of fellow developers attempting to make the stunt.
Since ForkLift 2.0 is a complete rewrite of the project, going for the new architecture and new APIs was an obvious decision to make. The particulars are, as always, more complex, but the bottom line is: we want to keep our code as simple and robust as possible, to be able to maintain and evolve the code as fluidly as possible, and the system features in Snow Leopard will support this very well.
Of course, it feels a bit like starting on a mission to Mars – there’s this vision, quite detailed, of a bright new future before us, but still with months of tedious traveling before actually getting there.
The ETA for ForkLift 2.0 is Q1 2010.
Good nights everyone,
[...] This post was mentioned on Twitter by Ticci and BinaryNights. BinaryNights said: Say hello to 64-bits: http://bit.ly/3sPNsk [...]
No complaints here, though I have to say I’m not terribly impressed with Snow Leopard so far. I’m hoping 10.6.2 brings about some stability fixes. (In the meantime, I’m going to try a fresh install from scratch.) I’m pretty happy with 1.7.5 and would only ask for enhancements in Sync features and Batch Rename UI, but I guess I’ll have to wait for 2.0.
@Nate Clean install does help. My college had crashes all the time but since he reinstalled it from scratch it’s been rock solid.
Hi guys,
instead of claiming a new super version 2.0 for SL that will maybe be available in 2010, you should focuss on fixing the existing Forklift version for SL.
At the moment it’s not usable (network shares) and its just taking too long to fix it.
/René
@Rene
As I’ve tried to hint at in my recent posts, fixing 1.7.5 is a current concern of ours. The one major fix that’s left on our short term list is the AFP problem you referred to, but that’s something where we’re waiting for the ball to get back from that other court. By the way, our query did advance some over the past weeks, but sadly no tangible result. If anyone reading this has some influence over the OSX developer team, please say a few good words in our favor.
Does 64bit mean _only_ 64 bit? My macbook (Dual Core Duo, without the “2″ in it) runs fine under Snow Leopard, hence it only supports 32bit. Well, but by 2010 I will have to upgrade my hardware sooner or later…
@Steffen
Good question, and the answer is No. ForkLift 2.0 will be Snow Leopard only, but will be able to run in 32-bit mode.
Hi people!
Would Forklift 2.0 be a free of charge update for actual users? Or a major charged upgrade due to its rewrite? Would it contain localization? I’ve seen in your forum that it’s on its way, but I can’t wait to know
.
Besides, I will thank you for this very good software.
@gnu
Yes, 2.0 will be a paying upgrade, on accounts that it is a major rewrite, and also because we’ve never had a paying upgrade in over 2 years, so we’re ready to try that now
Regarding localizations – the 2.0 release itself will not contain localizations yet (it would be too hard to manage UI localizations along with the beta test and all) but it will be ready for localizations. So I hope to be able to release the first localized version in a couple of months after the 2.0 final release.
To bad to pay for the upgrade
You cant even unpack files with Forklift…
Long way to go to make it like Total Commander!
What do you mean you can’t unpack files? Here’s a link to our wiki (http://wiki.binarynights.com/index.php/Main_Page), but the short version is: just enter the archive, and copy the files you need from it.
And I agree – I think we’ve surpassed TC a good while ago, so it would be a long way to go back
I just registered ForkLift 1.7
Will there be a cheaper price for an 2.0 update. Or is it one price only for updaters and new users???
csaba, what about 20 zip files. I want to unpack them all in once not one at the time. That so 1970’s
@spx
Place “Archive Utility.app” in the side bar. Drop there the files you want to unpack. It also works to pack… at least .zip
Hope it helps.
@csaba
“And I agree – I think we’ve surpassed TC a good while ago, so it would be a long way to go back
”
WTF?
We all know your special kind of humor, so I hope that this IS a joke. I’m a confident User of FL and I think, that you have made a fine piece of software but in almost NO way FL is better than TC.
TotalCommander has a fully customizable UI, a huge bunch of plugins and plugable filesystems. With FL you can’t even create your own Buttons or own customcommands. It looks much little better than TC, but who cares when functionality lacks? Quicksilver and Applescript-support should the way to go to catch up to TC.
Kind Regards
Thorsten