Paint.Net v4.0

[codekaizen]

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?

[Mike Ryan]

Answered via PM

[Rick Brewster]

Yes, I have been working on Paint.NET v4.0. I have not made a lot of visible* progress yet; I've so far been focusing on some foundational work to implement things like Inversion of Control (IoC) and a new asynchronous programming model.

Source code is not available for in-development releases. Only for versions that have been made public.

* "Visible" in the sense that, as a user, you wouldn't notice much difference.

[Mike Ryan]

Yes, I have been working on Paint.NET v4.0. I have not made a lot of visible* progress yet; I've so far been focusing on some foundational work to implement things like Inversion of Control (IoC) and a new asynchronous programming model.

Source code is not available for in-development releases. Only for versions that have been made public.

* "Visible" in the sense that, as a user, you wouldn't notice much difference.

From what I understand, isnt that stuff a lot more inflexible? I understand the concept of simplified actions and all... perhaps you could explain a bit more as to the reasons you are using that*?

*You dont have to, of course.

[Rick Brewster]

Inversion of Control isn't something that you would notice in the user interface. It is something that enables loose coupling in the code I write. It also enables me to "hide" services -- for example, plugins should not have access to the resource loader of the main application. I simply won't make available an implementation of IResourcesServices to them via the IScope reference that I hand over.

[Mike Ryan]

I understand the overall concept of IoC, I have been attempting to learn C# for the past month and a half. I just wasnt sure what internally you would be wanting to make changes to because from what I understood IoC isnt flexible. Though on a plugins based system as you describe, I can understand the necessity (or feasibility) of IoC.

[Rick Brewster]

... from what I understood IoC isnt flexible.

I have absolutely no idea how you came to this conflusion. The whole point of IoC is flexibility!

[Mike Ryan]

Thankfully it was just conflusement. I had always believed IoC was based over assigning methods, and not flexibility.

[Rick Brewster]

http://en.wikipedia.org/wiki/Inversion_of_control

In Paint.NET this will be applied in the use of a scope object. This will be how code will access services and classes that are registered in the system. For example, I could register the IFileOpenDialog as a class and then in code you say ...

IFileOpenDialog ifod = Scope.Create();
ifod.Show();

There are two implementations of this dialog: ClassicFileOpenDialog (for XP), and VistaFileOpenDialog. Your code doesn't know, nor does it care, which one it's getting. It just cares that it adheres to the contract laid forth by IFileOpenDialog. At app startup I'd run something like this ...

ISystemInfo isi = Scope.GetService();
if (isi.OSVersion >= new Version(6, 0))
{
   scope.Register();
}
else
{
   scope.Register();
}

[Mike Ryan]

Sounds interesting, and actually very flexible. Definetly something I will look into more. Thanks for clearing things up!

[Braiden]

Hmm.

I dont suppose you would use IoC to stop access to things like Version Number etc etc? Because making a Plugin comparison for my Manager would be near impossible, unless i read the file properties, in which is a longer way ( or so i think )

It does seem quite flexible, yet im sure there are work arounds possible?

I dont know tbh, ill look into it as Mike Said!

[codekaizen]

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?

[Rick Brewster]

I've already built mine from the ground up. It's pretty simple, and this way I have full control over it.

[Mike Ryan]

Will your container still be contained under the MIT license or is it to early for decisions on licensing?

[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.

[Rick Brewster]

The "container" (the scope object, in Paint.NET) really doesn't need much complexity. It just needs methods for creating a class, or retrieving a service. All the other things you mention can be implemented in services that are registered into the scope. IRemotingManager, etc. The new asynchronous programming model will obviate the need to work directly with threads as much.

[Hellowmate]

I hope the version of paint.net comes out the way you wanted it to.

Good luck,How are you doing so far do you have a 'preview'?

If not then not to worry,just tell us what you have done so far.

[barkbark00]

I would guess that most of what "he has done so far" would be way over most of our heads...lol

[Rick Brewster]

I hope the version of paint.net comes out the way you wanted it to.

Good luck,How are you doing so far do you have a 'preview'?

If not then not to worry,just tell us what you have done so far.

There's nothing to preview ... There is no difference that a user would see yet, nor will there probably be for awhile.

[Mike Ryan]

I hope you don't change to much about the way it looks. Keep features elegant, clean, and simple; that is what I say.

[Hellowmate]

I hope the version of paint.net comes out the way you wanted it to.

Good luck,How are you doing so far do you have a 'preview'?

If not then not to worry,just tell us what you have done so far.

There's nothing to preview ... There is no difference that a user would see yet, nor will there probably be for awhile.

Ok It doesn't matter.. Can't wait for it!!

[Rick Brewster]

I hope you don't change to much about the way it looks. Keep features elegant, clean, and simple; that is what I say.

Yeah the goal isn't really to change things around like that. While doing some design on 3.0, way back when, I did a lot of sketches to see what kind of UI changes might work out. Eventually I decided, hey you know what, the UI works pretty well as it is ...

[MiguelPereira]

yes it works very well...

but if your are planning on developing the so wanted brushes, wouldn't the gui need some update or two?

[Mike Ryan]

Custom Brushes is a planned feature and not confirmed for the v4.0 release, but expected sometime down the lifeline of the v4.** releases if I recall correctly.

BUT, and a big BUT, I have been thinking about some GUI changes myself recently. Nothing to big, but focuses more on productivity following up on the current GUI. Rick, if you would like I have no problem in posting these changes in a new thread.