Rick Brewster
-
Posts
20,659 -
Joined
-
Last visited
-
Days Won
378
Posts posted by Rick Brewster
-
-
This file is not available for download anymore. Version 2.5 has been completely discontinued.
-
Moved to Bugs & Troubleshooting
A few questions: What is the size of the image, in pixels? You can view the properties in an explorer window.
Second, please post the contents of the pdncrash.log text file, it should be on your desktop.
-
This sounds like either an error with this Windows functionality, or a misconception about how it works (I admit I'm also not sure how it decides to populate that menu). You may have some better luck if, from any Explorer window, you go to Tools -> Folder Options..., and then go to the File Types tab. Find TIF and TIFF in the list and edit them appropriately.
-
It's definitely a cost-effective place to start.
-
Figure out what DPI you need to have, and then scale accordingly.
For example, if you need 300 dpi, then you will need a (2*12*300) x (3*12*300) pixel image. Which is 7200 x 10800 pixels, which is probably too big to fit in memory (w/ Paint.NET) unless you're on a fully 64-bit system.
-
I really can't help you here, for several reasons. I don't know what you're trying to do. Your summarized list is not really helpful, as to do a good estimate one would need a much fuller, detailed specification. Nor do I know anything about your dev team (size, experience, etc). Plus, I really just don't have any time to help out here (even for an estimate unfortunately), nor do I offer consulting services for Paint.NET-forked projects. I also don't know your distribution intent -- internal tool, or something that you'll be charging people for? The latter will have significant legal obstacles.
Anyway, I'm not trying to be a jackass, I'm just trying to verbosely state that, well, you're basically on your own. Good luck!
-
Moved to Coding / Development
-
Thanks for triple-posting.
-
Moved to General Discussion
Nope, sorry, it only loads the first page. Please make sure you post questions like this in the right section.
-
It's not really a sore point, it's just something that I don't think search engines are currently handling correctly, so I was venting w.r.t. that.
And don't worry, Paint.NET is indeed growing and growing. We're easily doing 30,000+ downloads per week ... which is astronomically higher than 2 years ago
-
You're starting with season 1 right? That TV show is great.
P.S. draw more comics :-P The George vs. GI Joe one is a riot
-
Well if you ask me, if you want paint.net you should type it into the address bar of your browser. The search enging shouldn't go, "OHHH I'll bet you want http://www.paint.net so the results list will just be a link to that." *bonks head* It makes sense for it to be the first result, sure, but not the only one.
I think MSN Search, et. al. do this as well.
In the end, it's not worth selling my car and taking out a loan for. (to buy the domain)
-
Hey we tried to buy the domain from Warren (http://www.paint.net), he wanted $50,000 or something ridiculous.
-
Hmm, other people have had success with this so I'm not sure why it's throwing errors at you. I am not very familiar with AD deployment, nor do I have access to an AD network where I am an administrator, and have had to implement this stuff relatively blindly. I don't know why these errors would cause problems with configuring a group policy deployment.
PaintDotNet.Resources.dll is indeed targeted twice in our MSI, but it's because the setup project in Visual Studio does not handle dependencies correctly in some cases (if you include project A's "primary output" which is an EXE, and some other B.EXE, both of which depend on C, it will include C twice in the MSI).
Go ahead and post the full Orca results, I'll see if I can find anything in there.
-
Made into an "announcement" so that it stays at the top of the forum
-
This is a Paint.NET forum. Stay on topic, or posts/threads will be edited or deleted.
-
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!
-
Sorry, we don't accept external code submissions. Thanks though!
-
We have a bug database that keeps track of bugs and work items. Sometimes those work items get punted from version to version, but we don't close the ones we're still interested in implementing. For example, "make Paint.NET localizable" was punted all the way from v1.1 to v2.5 until it was actually finished.
But we don't have a public roadmap partially because Paint.NET is a part time project and we need the freedom to do whatever the heck we want.
-
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.
-
Moved to General Discussion
This is currently being implemented. And yes it is requiring enormous changes to the design and code.
-
This is normal. Paint.NET's dialogs have long since grown past the bounds of what the Visual Studio Designer can handle, esp. because of the way we do localization. Or rather, we haven't had the time to figure out a way to make them work in the designer. We just edit the code.
-
Look for the ShellExtension_IA64 project in the solution, and remove it.
It requires the Itanium C++ compiler which is not present except in the very expensive editions of Visual Studio.
-
it seems to me this might be the sign of a great program. It's easy for members to use, and works well for them. So they have no need to post!
This is true, but.... what i'm getting at... is it would be nice to see more people log on and share in what they do or what they have learned while working in Paint.NET. I think if more people would do that, we could all learn from each other and/or draw ideas off each other. :wink:
Well, this is happening over time. A year ago the forum was pretty much (1) bug reports, and (2) suggestions. There was no "pictorium," etc. The community just takes time to grow
Downloading the source code for 2.5
in Plugin Developer's Central
Posted
Nope and no.