Jump to content

Recommended Posts

Is a multiple document interface (MDI) planned for a future release of Paint.NET? Currently, it's a single document interface (SDI), so each time you open another image, a new instance of Paint.NET must be launched. I take it that such a change would require drastic changes to the interface design?

Link to comment
Share on other sites

Oh wow, that's a big question.

If you work on developing software long enough you have probably heard the term layer or layering (and no I don't mean layer in the same sense as a layer in a Paint.NET image). Check here for some more info on that: http://blogs.msdn.com/larryosterman/arc ... 55193.aspx

The layers in Paint.NET never had to take more than one document into account -- or less than one (zero) (quick recap: an image in paint.net is internally called a Document). As such, all operations and variables had the luxury of essentially being global. Some layers of Paint.NET blurred together a little, but it didn't matter because of the relative smallness of the application and because there was no short- or mid-term consequence.

The thing is, with MDI, you have multiple Documents. Or just one. Or zero. We have to figure out which settings are application-global, and which are document-specific (or rather, workspace-specific). For example, the zoom level is workspace-specific, but things like brush size, text font, anti-aliasing are application-global. There are also things which are application-global from a UI level but are actually workspace-specific (like which tool is active), so there are some smoke and mirrors (or there will be!) to accomplish that.

Along with this I'm taking the chance to really refactor things to keep the code more pedantic, maintainable, and robust. For instance, right now we have to handle every operation's out-of-memory condition explicitely. So for (example) 30 operations we have 30 out-of-memory handlers. Now we only have 1, which also means that every operation automatically gets this kind of protection, as well as reliability contracts that let them specify whether they were in the middle of doing something that can or cannot be rolled back.

Along with that is figuring the scope at which operations must execute. For instance "Invert Selection" executes at the scope of the document workspace, and "Print" executes at the scope of the Document. Effects execute at the Layer scope, and "Open" executes at Application scope (because it must create a new document workspace to place the new image in to).

There are also some things I'm doing that should enable the possibility of automation and maybe even scripting. I'm not saying we'll have scripting for the next release, but hey you have to lay the framework before you can build something on top of it.

The gritty details? ...

Paint.NET v1.0 through v2.61 had the basic architecture that pixels are grouped into layers are grouped into a Document which is rendered by a DocumentView which is housed in a DocumentWorkspace which is housed in the MainForm (form = window). There was also the DocumentEnvironment for storing certain settings (brush size, antialiasing toggle, font size/style, etc). Any changes to the document were recorded in the history, usually through DocumentAction objects.

The next release will change this: the DocumentWorkspace was split in two, resulting in a new DocumentWorkspace that was actually merged with the DocumentView, and an AppWorkspace which holds 0-or-more DocumentWorkspaces. DocumentEnvironment was renamed to AppEnvironment and anything document specific was moved into DocumentWorkspace. There are also many other changes related to how the history is defined, changes are recorded, and actions are executed. Oh, and AppWorkspace will probably be merged into MainForm.

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

For example, the zoom level is workspace-specific, but things like brush size, text font, anti-aliasing are application-global. There are also things which are application-global from a UI level but are actually workspace-specific (like which tool is active) (...)

Is this a final decision? This isn't the only approach possible, it's not even the best one (there is no thing as the best approach ;)). From my perspective both current tool and tool parameters should be workspace-specific. Imagine the following scenario: you're making an image processing using copy/paste technique. You want to take a piece of one photo and place it on the second one. You surely want selection tool active for source document and move tool for target. If you want to create a fancy rounded corner shape on target layer, you'll need selection tool for both, but rect. sel. for source and round sel. for taget. There are lots of scenarios like these two...

Best regards,

Dominik Dalek

Link to comment
Share on other sites

Dan, don't hold your breath :) An alpha is a long ways away.

Dominik, I wouldn't go claiming best/worst/only until you use the thing. Trust me, it would be hellishly confusing for the active tool to change whenever the user switched the active image, because the Tools window is a "global" choice in the logical sense. Basically when the user clicks to change one thing (the active image), it should not change something else! Anyway we have a long time before anything is "final" or will even be available. Please trust that we'll get it right!

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

You have one menu for the whole application as well, but some options will be enabled/disabled when you switch between documents (e.g. one layer doc should have "flatten layers" option disabled).

In real life if you have two easels, one for sketching and one for oil painting and for some reason you prepare both pieces simultaneously, you definitely don't want the same tools for both. The fact that you have one tool dialog does not mean you should stick to one active tool, color, etc. per application. From my point of view - tool and color assigned to document is more intuitive (although most apps have them common for all documents).

But still, it's your decision. :)

Link to comment
Share on other sites

Dan, don't hold your breath :) An alpha is a long ways away.

Eh, that's ok. I still have to make a Basics tutorial for 2.6[x] anyway. Best time to do that is in the lull between versions, because for [whatever the next release is numbered], there'll be bunches of changes I'll have to make for the whole "Intro to Paint.NET" thing. I'd want to test PDN on my laptop, being that my laptop is my primary workstation, and I'm also making the tut on my laptop, so I'll need to finish the tutorial before I test new versions anyway.

Still, though, I'm excited for the future! Onward!

*gallant charge forward*

I am not a mechanism, I am part of the resistance;

I am an organism, an animal, a creature, I am a beast.

~ Becoming the Archetype

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