Jump to content

Paint.Net v4.0


Recommended Posts

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?

Link to comment
Share on other sites

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.

The Paint.NET Blog: https://blog.getpaint.net/

Donations are always appreciated! https://www.getpaint.net/donate.html

forumSig_bmwE60.jpg

Link to comment
Share on other sites

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. :)

signature.png

Link to comment
Share on other sites

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.

The Paint.NET Blog: https://blog.getpaint.net/

Donations are always appreciated! https://www.getpaint.net/donate.html

forumSig_bmwE60.jpg

Link to comment
Share on other sites

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.

signature.png

Link to comment
Share on other sites

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();
}

The Paint.NET Blog: https://blog.getpaint.net/

Donations are always appreciated! https://www.getpaint.net/donate.html

forumSig_bmwE60.jpg

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

The Paint.NET Blog: https://blog.getpaint.net/

Donations are always appreciated! https://www.getpaint.net/donate.html

forumSig_bmwE60.jpg

Link to comment
Share on other sites

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.

The Paint.NET Blog: https://blog.getpaint.net/

Donations are always appreciated! https://www.getpaint.net/donate.html

forumSig_bmwE60.jpg

Link to comment
Share on other sites

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!!

Link to comment
Share on other sites

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

The Paint.NET Blog: https://blog.getpaint.net/

Donations are always appreciated! https://www.getpaint.net/donate.html

forumSig_bmwE60.jpg

Link to comment
Share on other sites

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.

signature.png

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...