The effects system in Paint.NET is generally a well thought-out system and great for someone like myself to develop against (hey I wrote it, so I know all the rules!). It was designed to give all effects the same support and workflow for selection clipping, user cancellation, multiprocessor/multicore scaling, and preview rendering.

However, when extended for plugins, it has not held up to the test of time.

“But just wait a second!” you might yell. “There are tons of plugins on the forum, and some of them are really good!” You’re probably referring to things like the EdHarvey Effects pack, or the DirectX Surface (.DDS) plugin by Dean Ashton. These are the types of plugins that really extend Paint.NET’s usefulness and cause developer envy in myself … but I digress! J

This effects system is definitely a case of something that was written by one developer (me), for two developers (myself and Tom Jackson). However, for a very long time, it didn’t matter because there were no plugins! Paint.NET wasn’t popular enough for anyone to have really written any of them, and the community was small – maybe 1 or 2 posts to the forum on any given day. In fact, between version 2.5 and 2.6, I made changes to the system that completely broke all plugins written for 2.5 and before. This was back in February 2006, and I didn’t get any grief e-mails about it. Nowadays if I make the slightest change, such as moving a class between DLL’s, I get e-mails from many users whose plugins are now causing crashes! (Which brings to light another problem, that of robustness, but that’s another topic.)

Some people have so many plugins installed that they are crying out for a way to organize them in to sub-menus of their choosing. Their Effects menu gets so big that they have to scroll around to find their effects!

As a developer and publisher of software, this is the absolute best kind of problem you can have. Think about it: people wouldn’t be asking for an “organize effects” feature unless there were lots of effect plugins!

Wow, what a difference one year makes! So right now there are a number of problems that I’m hoping to solve in the next release:

1. Make it easier for casual plugin developers. Not all plugin developers have a computer science degree and a day job as a software engineer. Nor would they want to! (Heck, most professional software engineers would rather be doing something else, to be brutally honest.) A lot of people right now are making plugins by using CodeLab which was originally only intended to provide a rapid prototyping environment – turns out people are perfectly happy using the DLL’s it spits out!

   On the forums, BoltBait has even extended CodeLab so that it will automatically generate a user interface by adding a small amount of metadata to your script file. However, it is limited to the very basic UI dialogs that are built in to Paint.NET. BoltBait doesn’t exactly have time to pour in to CodeLab to turn it into Visual-Studio-inside-Paint.NET, complete with syntax highlighting and a UI designer. I think he’d rather spend time with his family, for instance, and I don’t blame him.

   I’d like to make it so that you can tell Paint.NET to automatically generate a user interface based on some schema that defines the properties for your effect. Maybe you can throw some XML at the effect system, like <Property Name=”Blurriness” Minimum=”1″ Maximum=”100″ Type=”Int32″ /> and it will figure it out.

2. Make it easier for plugin users. Right now you have to download the DLL … or the ZIP … and then figure out that you need to extract it to C:\Program Files\Paint.NET\Effects. Oh, and don’t forget to close Paint.NET and restart it. Also, if you downloaded a DLL then Internet Explorer will tag the file as “blocked” so you have to right click it, hit Properties, and unblock it. Etc., etc., argh! It’s no problem for myself, or other developers. File system acrobatics are second nature. But if I were to tell my mom how to do this, she’d be lost.

   I like to call this the “I have a dll, now what?” problem:

   
   (image from: http://icanhascheezburger.com/2007/05/30/i-has-a-money/)

   This is not to disparage the many users who have asked about this. It simply highlights that, to most users, a DLL is a weird foreign object much like the quarter is for the kitten.

   So, like I mentioned in an earlier blog post, I want to make this a lot easier! Right now the idea is to have a container format, maybe using the extension “.pdnmod” (Paint.NET Mod) that would basically be a renamed ZIP file. Once that extension is associated with Paint.NET, installing a plugin will be as simple as linking to a .pdnmod on a web page and then clicking the appropriate approval dialogs.

   This container format will also simplify, standardize, and/or facilitate things like attribution (“copyright so-and-so”), localization, and automatic generation of UI based on a schema for property values (as mentioned above).

3. Extend what the Effect system is useful for. Right now there is some confusion about the effect system and how it works. “Why is my Render method called hundreds of times!?” Some people are trying to use it for image analysis (“analyze pixels, write data to text file”), which it is just not intended for. There is also the really big problem that implementing multi-pass rendering algorithms isn’t really feasible right now. Some people are, to be honest, horribly abusing the effect system and going outside the rules just to get it to do what they want. To that end, I’d like to make the workflow a little more customizable so that they don’t have to do these terrible things.
4. Provide documentation. This is where the title of this post comes in to play. People are writing effects even in the absence of any real documentation! So … I think I will write some, finally.

Anyway, that’s about all I have to say right now. I’m taking this week off from my day job, so I’ve got plenty of time to catch up on things and go enjoy the sunshine here in downtown Kirkland.