codekaizen

If the container is simple, it's a good choice to do it yourself. However, containers have a way of attracting a lot of functionality and getting complex quickly. Service and component lifetime and thread management, activation models, dynamic proxying of components, container extensibility, etc., can quickly become a large sink of development time. With a document-centric app like Paint.Net it probably won't put so many burdens on the container to allow a simple one to suffice. However, I'd be interested in the opportunity to build a robust scene model and rendering engine, which could be quite parallel in architecture and even distributed in time. This means that component lifetime and inter-component communication becomes important - something that a good container might take care of. Another interesting aspect for Paint.Net is the large number of commands. As components are added, those which can respond to commands could be registered and this will need to get tracked. Doing this in the container is a natural way to take care of this, increasing complexity.

Implementing an IoC container is a good choice if you want to maintain modularity. I decided against it early in the SharpMap v2.0 development, seeing as I couldn't decide which one to use, and I somewhat regret it now. For example, we read geographical data from various sources, perform computations on it, and then need to render and present it. The renderer and the model/view/presenter classes are modular, and can be replaced depending on which graphical system you want to display on: GDI+/WinForms, WPF, or DirectX. Getting all this wired up takes a lot of code, and a container managed wireup would be much smoother. IoC is the right way to go. Which one are you looking at, or do you intend to build the container from the ground up?

Greetings, I've been working on a similar library to Paint.Net (SharpMap), and I've been thinking on how to apply some of the concepts I've developed there to a more general graphics tool. Paint.Net sprang to mind. Is anyone working on v4.0 yet? Last I checked in it was still mostly just some ideas. Since that time, I've been able to develop a practical working experience with general computational geometry, scene management and representation, and visual graph and tree computation. Some or all of these would be useful to a next generation Paint.Net. Is there is a codebase other than the published 3.x code which contains any of the 4.0 branch work?