In my last post about Paint.NET v4, I said that I was going to be writing it "from scratch" — that it would be a rewrite from the ground up, in other words. I’ve since changed my mind.

You see, I got a few months into this rewrite project. I wrote a lot of code — 26,000 lines of it, in fact. However, the continually daunting task of finishing the next 150,000 lines of code and doing a reset on the 4 years of bug fixes in v3.xx made things … depressing. So, I’ve decided that I will turn back to the v3.xx codebase and work towards v4 from there.

However, don’t worry. The rewrite project, which is now called a "prototype," was not wasted time. I was able to work on and experiment with a lot of stuff in a nicely isolated fashion, and I now have a much better idea how I can refactor these into the existing [v3.xx] codebase. This includes some things for stuff like task management, extensibility, eventing, asynchronous programming, retained mode rendering, and an improved document model. This is actually a good example of quantity beating quality: by being able to iterate on all this enormous amount of code in isolation without the burden of the existing code base, I’ve been able to fine-tune it towards perfection.

In fact, I can’t stress that one word enough: depressing. Having 150,000 lines of code worth of work to do before you can even have something that’s feature parity with your already-shipping product, and that your users will even be interested in, is not fun. Next time you hear yourself thinking, "Rewriting this would be worth it," stop and switch over to thinking about prototyping in an isolated codebase instead of rewriting the existing codebase. I can write a lot of code really fast, and I like to think I’m very good at it, but this was just too much for me. Your code (and mine) may not be academic-proof or astronaut-quality, but that’s ok … because it already works.

Now, why don’t I talk some about version 4 itself and what’s happening.

The first features that I’ve been working on are focused on the installer and the updater. First, the installer will internalize the progress bar stuff — it will no longer have those annoying "child windows" for when it is installing things. For the update process, I am going to give a nod to Firefox and how it lets you install the update once the current session is complete. This is in response to a lot of feedback I’ve been getting from people who never install updates because they just want to get something done right now, and can’t be bothered to wait a few minutes for the update. It’s completely understandable — I do it myself. Changes to the installation and update code are always risky business, and as such I had been delaying these until I had a long, full test pass available (in other words, a major version update). And, to explain why they are risky business: if the installer or updater fails, then the user can’t use the product. Statistically speaking, they have disappeared from your userbase. They are gone. If your installer and updater work, then your Priority 0 feature is always making sure that it continues to work!

Oh, also, the installer will do a much better job of getting the .NET Framework installed if it isn’t there already. I’m taking advantage of the new Client Profile that’s available with .NET 3.5 SP1, and it rocks: it’s only about 300KB to include the bootstrapper!

This change of direction shouldn’t result in any lost or cut features. If anything it will dramatically shorten my schedule for v4. This is good news.

And in other news, expect a version 3.36 update once the Olympics are done. It will be a servicing release to fix some bugs, like the canvas background color one. I’ve settle on #c0c0c0, which is what Photoshop uses.

Advertisements