So version 3.08 is fresh out the door, which means it’s time to start on the next release! The last few releases since v3.0 have mostly been servicing releases (aka “bugfix releases”), with a few features and refinements thrown in for good measure. Service releases are important in order to fix top pain points for users, but it’s also great when some new features are introduced too (even if just a trickle). Not everyone is affected by every bug, so why force everyone to download the fix for it? If I add a trickle of new features or refinements, then everyone is able to benefit from even a +0.01 update. And then I get to go drink beer! It’s a win-win-win scenario.
Anyway, I’m currently planning out the next two major releases: “3.Next” and 4.0.
“3.Next” might end up being named 3.20, and that’s how it’s described on the Roadmap page. The big area I want to focus on in this release is the experience around plugins, for both the user and the developer. I will be creating a new, richer plug-in API (and adapters for old plugins, don’t worry!). The user interface will allow you to install these plugins right from within the application, and to enable / disable them individually without having to muck around in the file system. Users have also been crying out for a way to organize their effects into submenus, and I’m hoping to provide that as well. You’ll also be able to install a plugin just for yourself, or for all users on the system. Maybe I can also provide a way for plugins to be able to check for their own updates and to then invite the user to install them (like Firefox does). I also want to make it much much easier to write UI for Effect plugins. Right now it is a very clumsy experience.
Along with the plugin management, I think it’ll also be very useful for Paint.NET to allow you to configure the file types that it is registered to handle. Right now you essentially have to re-install Paint.NET to get to these options. Granted, these aren’t options that you really need to touch very often, but when you add file type plugins it’s another ballgame: if you install the DDS plugin, how great would it be for Paint.NET to be able to register itself to handle *.DDS? Right now these file type plugins are on their own, and it sucks for the user.
As you may be guessing, this means that “3.Next” will have a Configuration dialog (aka Options, Settings, Preferences, etc.). I have always been fiercely against providing a dialog like this in Paint.NET because they can easily degrade into a buffet of confusing checkboxes, radio buttons, and all sorts of propeller-head idiocy. Sometimes you end up needing a large supplementary manual just for this portion of the user interface. I recommend that you read Jeff Atwood’s Coding Horror blog post from last November, “This Is What Happens When You Let Developers Create UI“. It’s a good read J
The Configuration dialog in “3.Next” will only provide options that really matter. There will not, for example, be a “Tile Cache Size” option, or anything else that requires 3 pages of text to explain. Those are things that the application should be able to optimize itself, and that the user shouldn’t need to give a damn about. The Tool->Choose Defaults and the updater options will also be consolidated here.
Version 4.00 is going to be a whole new ballgame, and is also discussed briefly on the Roadmap page. There are certain areas of Paint.NET that, quite honestly, only work because they have been thoroughly debugged. I have identified three areas that are in need of major overhauls: the data model, the application model, and the image rendering engine. So basically the entire program (oops).
The data model needs to be more resilient to nested actions. Right now the application is given direct access to the data and expected to “do the right thing.” That sort of trust never scales over time, not even on a relatively small project like Paint.NET. I want to move to a more transaction-oriented system, with support for nested and ambient transactions.
The rendering engine right now is pretty simple in Paint.NET, consisting of methods called Render() that are given a target and a region of interest. This works great for linear composition, but nested composition is out of the picture. What if I want to attach a mask or an adjustment to a layer? I can’t do that right now because I don’t have a 3rd rendering buffer, nor do I want to require the memory it takes to do that. So this means the rendering engine must move to working with tiles instead of whole bitmaps (yes, just like every other non-Paint editor out there J). Tiles are generally light weight and can be cached, copied, paged out to disk, paged in to memory, etc.
The application model needs to be refactored so that it separates front-end (user interface) from back-end (logic). This and the data model changes are tightly intertwined, and will provide the foundation for such features as scripting and automation.
That’s enough writing for now. Hopefully this gives some good insight into the direction that Paint.NET is going, both short-term and long-term.
Paint.NET Blog 