anderpainter

Yup, it's enabled. Actually, when you make a selection—let's say, with the Lasso tool—then delete it, PN does antialias to a small extent: But the eraser tool really antialiases: I can make very accurate selections using the Magic Wand, Lasso and other tools, but they leave such sharp edges, they're not very useful this way. It'd be awesome if they could have the same AA quality as the Eraser. Or am I overlooking some logical reason that they don't? Couldn't it at least be an option?

Also, if you post something here and forget to click the "Notify me of replies" button, is there a way to turn notification on afterward? Most forums have a button for this, but I don't see one here. (Fortunately, I can click it before I save this post...)

In other graphics apps, I could paste an image into a new layer, select and delete the background around it, and the app automatically antialiased its edges to the layer(s) beneath it: When I do this with Paint.net, it doesn't AA the edges: I must then run the Eraser tool along all the edges to AA them. This takes a lot of extra time (mostly to avoid erasing more of the image than I want to). Was this intentional? Is there any way to make PN AA such cuts automatically? I can't be the only PN user who wants this. Thanks!

Hey guys, I've noticed that with the latest P.n (v4.0.13), when I copy an image and paste it as a New Image (Ctrl+Alt+V), a message appears: Copying selected pixels... ...with a progress bar, and I must wait several seconds for the image to appear. Granted, I'm on an older, slower PC—but I still wondered why that was happening now, and if it was intentional. And while I'm at it: _ How come there's no way to preview a message here before you post it? This is the only forum I know where you can't do that. _ In your version numbers, why do you follow this format?: Paint.net 4.0.13 (Final 4.13.6191.1824) Why not just call it v4.13, and follow that with the full number?

Hi, P.N seems unusually slow—at least on my system—at saving larger images. For example, I'm currently working with an image that's about 8K x 8K. When I saved it as PNG, then again as GIF, P.N took nearly a minute to create each preview, then nearly another minute to save the image itself. At these times, I noticed P.N was using only about 25% of my system's quad-core CPU. Could this mean that P.N can't utilize more than one core at a time? If so, can that be improved? Also, could it be easier to skip previews when saving images? When I click OK in the preview window, P.N. seems to cancel the preview (a "Save Configuration" dialog box appears that says "Canceling..."), but this doesn't seem to shorten the time I must wait till the "Save As..." window appears. (And BTW, when you Edit a post here, the button to save your changes is cryptically labeled Edit Topic—which you're already doing. Save Changes seems more intuitive.)

My teenage son's wondering if it's possible to write a plugin that'll make P.n do celebrity impressions.

BoltBait > I've never had the docker windows get lost. But, I've seen tons of posts from people that have lost them. Until recently, it was a pain to get them back (you had to use regedit)... I could rewrite my plugins to always show up where you left them, but WHAT A PAIN! ... With all due respect, the process is pretty straightforward: 1. When user closes a dialog box, record its x and y positions. 2. When the user opens a dialog box, check the user's current screen resolution (people do change them) and the box's dimensions, as reported by your IDE (which should automatically reflect its size in the current resolution) and see if placing the at the recorded coordinates would cause any or all of it to appear off-screen. If it would, decrease the box's x and/or y coordinates to accommodate its width and/or height. If it wouldn't, just restore the box. In other words, before you open a dialog box, be sure you're not placing any of it off-screen. As long as the user hasn't set their screen resolution smaller than the dialog box itself, there shouldn't be any problems. :?) BoltBait > Actually, the quoting system is pretty cool. All you need to do is select the part of my message you want to quote and a little bubble shows up. Click the bubble and the quote happens. Hey, that is cool! I'll have to try it next time. anderpainter > You're saying you can use them to affect P.n's default behaviours? toe_head2001 > No, you misunderstood what BoltBait said. What he was saying is that you could modify a plugin so that it (that specific plugin, and that specific plugin only) opens its dialog in a different location. Yes, I'd assume the plugin language would let you determine where your forms opened—but unfortunately, that doesn't address el problema aquí—unless you're suggesting I write my own versions of all of P.n's features. I'm a bit short on time to take on something like that.

This forum has a rather draconian quoting style, so I'm going to wing it here. (Hey, we're creative types, right?) BoltBait > Now, you want two different behaviors?! That's even MORE code! My pointer-centered zoom request is new. I've been carping about P.n's always-in-your-face dialog boxes for years now. I don't have much hope that'll ever be fixed. But P.n is still my favourite graphics editor, and I must cope with that frustration each time I use it—so I say something about it every few months or so. And since I was posting here anyway... Ironically, neither of these changes are major modifications. As I've pointed out, Rick has already coded P.n's palettes to behave this way. And like persistent form positions, pointer-centric zooming has been default graphics-app behaviour for many, many years; you can probably just copy and paste that code from any number of programming resources. BoltBait > You're right that Rick has written a bunch of this code... but, you know what? Sometimes those windows get lost! Then why don't the palettes "get lost"? I've haven't seen that happen yet, have you? We're talking about the exact same functionality. Why Rick thinks one is worthwhile and not the other is beyond me. BoltBait > Many plugins ARE open source. You are free to recompile them for yourself and add in the necessary code to open the window where ever you want. Really? I thought plugins just added extra functions. You're saying you can use them to affect P.n's default behaviours? That seems like an entirely different thing. You've written plugins, though (I've used and enjoyed many of them, thanks!)—so if you say it's possible, it must be.

If P.n were open source, I'd add the code myself. As mom would've said, "It isn't rocket surgery."

The first three window-opening behaviours you described are just pre-defined for convenience. I can't think of anyone (anyone else, that is) who'd bother using them in this kind of app, where you're continually opening and using many small dialog boxes as part of your actual work, rather than just opening them now and then to change settings. People who work with graphics like to set up their own workspaces to accommodate how they work best. This includes arranging the positions of palettes and dialog boxes. For this reason, maintaining last-opened form positions is the absolute norm in all kinds of apps involving image manipulation. Besides, P.n's palettes already "remember" where you positioned them. So obviously Rick knows how to record form positions during and between sessions, and to perform a rudimentary check (and it really is simple; I've coded it myself) to be sure the user's screen resolution no longer accommodates a saved form position. This is not a matter of "writing LOTS of code"—all Rick need do is copy and paste some of his own code and apply it to the dialog boxes, too. I'm not even asking that persistent form positions be the default behaviour (although it is, almost universally, elsewhere). The default can still be "Always open every darn dialog box right in the middle of the screen, every time, so you always have to drag it out of the way." That's great—a charming P.n tradition or whatever. Just please add the option to make the dialog boxes behave like the palettes, that's all I ask. This doesn't seem unreasonable. It seems more like an appeal for normalcy.

Yes; that's what I was referring to in my first sentence. If you zoom in without holding Ctrl, P.n just zooms on the center of the current view, which I suppose it should. However, if you've just opened a dialog box to adjust image properties or apply an effect—and it's appeared smack in the middle of the editing area, as it does every... time... you... open... it, rather than where you left it the last time you used it (even during the same session, because we're obviously much too simpleminded to realize we've opened something if it doesn't appear right in front of us)—zoom is disabled. So you can't even zoom in so the dialog box you just opened obscures even more of your image. Okay, I know I'm engaging in topic drift here. But the always-centered-dialog-box thing is so '90s, I never pass up a chance to kvetch about it. (You can't see me, but I'm also shaking my head in continued bafflement at the developers's apparent apathy about such a pointlessly annoying flaw in such an otherwise excellent program.)

When you point to a particular place in an image and zoom in, P.n (usually? sometimes?) keeps that place from going offscreen. However, it'd be very useful if we could hold a certain key combination (e.g. Ctrl+Alt) while zooming, so P.n treated the pointer's location as the center of the zoom—assuming we'd pointed to the place where we wanted to examine and/or edit something and wanted to keep as much of that area visible as possible. To do this, as it zoomed in, P.n would gradually move the pointed-to place toward the center of the editing area: Eventually that place would be centered, and further zooming would zoom in on the center of the editing area. Programmatically, this would require P.n to determine: When the pointed-to place should become centered (e.g. a fixed percentage of the range between the present view and maximum zoom) The incremental amounts of horizontal and vertical shift, by dividing the distances between the pointer's x and y coordinates by the amount of zoom increments until the pointed-to location is centered. Not only would this ability keep the pointed-to area as visible as possible, it'd avoid obscuring it with open palettes*—which currently requires us to manually scroll the image away from them, or drag the palettes out of the way, to see what we're doing. * Assuming the user didn't leave a palette in the center of the editing area, of course... If they did, they'd have only themselves to blame. :?)

I guess Paint.net can't do this anymore? I've tried to find these functions in the current version, 4.10, and failed.

That's too bad... I suspect that if anything, most of us need to get out a bit more. :?)

Nope, I didn't mention the Zoom tool at all. (I guess you were too busy to read what I posted. That's okay—I know the feeling!) I was referring only to the new version's quirk of leaving images scrolled off (up and to the left, usually) when you reduce their size. Now that I can pay a bit more attention to this thread, I suspect this has something to do with the new Overscroll feature. That, in itself, doesn't seem like a bad idea at all. I'd use it to be able to start selections outside the image without having to zoom out first (allowing more selection accuracy.) But it shouldn't be activated when you resize... That's just confusing, and requires you to move the image back in view each time.

LOL—Google hasn't done anything "abominable". Alt+left has been a standard "Back" shortcut since early browser days. If you don't want to take your hand off of your mouse, just get one with a thumb button and map it to Alt+left. (If it bugs you to think that it's mapped to a shortcut you don't like, just think of it as being mapped to "Back." <g> ) I have a mouse with two thumb buttons. I map the second one to Undo—very convenient, especially with mouse-centric apps like Paint.net.

Hi guys, Is a beta available yet that fixes the bug where images remain scrolled over to the left when you reduce them? I'm also seeing this happen sometimes when I just zoom in or out. Sorry if you've already discussed this; I'm afraid I haven't time to read all the new posts here. Thanks, A.

I'm not sure what you're referring to. The post I moved to "Bugs" was about the latest version's quirk of not (always) re-centering the image after resizing (making it bigger). Can this possibly be a "feature"? Why would anyone want to be left looking at just the lower corner of a resized image? And if it is by design, why does it happen only sometimes? Nah, it must be an oversight. I'm glad it was helpful in that particular circumstance, but I don't see how see how such a randomly occurring benefit could be worth the trouble of (otherwise) having to scroll every enlarged image back into view. Normally, there is no reason for scrollbars to remain visible when an entire image is visible. In this case, though, I'm guessing P.N.'s developers wanted users to be able to de-center an image so they could start selections from outside of it, which can be useful.

I've noticed a quirk in v4.0.10: When you reduce an image's size, P.N doesn't center the new view as it used to, but leaves it scrolled off to the left. To reproduce: 1. Open an image larger than your display, then view it at its actual size. 2. Reduce the image's size. 3. The new image appears scrolled to the left, only partly visible. This seems to happen only the first time you resize during a session; subsequent re-sizings work normally until you exit and restart P.N. I also have a small suggestion for the forum itself: When you're not signed in, a button appears on each thread that says "Sign in to post a reply." It's not a link, though, just a graphic; to sign in, you must scroll to the top of the page and click "Sign in". Wouldn't it be convenient if the the button were a link to the sign-in page too? [edit:] Nope, the no-recentre quirk can happen during the same session. It seems random. The button actually says "Log in to post a reply", though the top link says "Sign in". Good thing you're not obsessive like me, or you'd want to fix that. ;?)

[moved to Bugs section; admins, feel free to delete this]

I got excited when I saw this. I thought, "Is it possible that P.N has finally joined the ranks of every other graphics editor in the known universe, and finally 'remembers' where you leave dialog boxes, so they don't always open smack in the middle of what you're doing and must be dragged out of the way every... single... time... you... use... them...?" Alas, no. I don't know why I got that idea. Wishful thinking, I guess. P.N's programmers obviously know how to save control locations, because those icon-related ones (Tools, History, etc.) are always restored where you left them—not just when you close and reopen them, but between sessions. That, my friends, is an otherwise standard practice that users have valued since, what? Windows 3.1? So what possible reason can there be for not making the positions of all dialog boxes [a.k.a. "windows"] persistent? Especially considering how often you want to preview your changes while the boxes are open? What possible reason can there be to having a box automatically obscure the image you're trying to use it to modify? To create a certain sense of mystery, perhaps? Or maybe to help us appreciate things that aren't chronically inconvenient? If only the rest of P.N weren't so good. It's like having a girlfriend who keeps feeling compelled to get up and stand in the middle of the room.

Sorry, I realize this is an old thread—but I've found this method much easier, and it doesn't require a plug-in: 1. Select your whole image, Cut it, then Paste it as a new layer. 2. Increase the canvas size by your desired border's thickness times 2, with your image centered. 3. Fill the Background layer with your border's color. 4. Merge the two layers. For those who aren't sure how to do that, I've written more detailed steps below. Cheers, A. - - - - Add a border to an image - 1. Select the whole image (Ctrl+A). 2. Cut (Ctrl+X), then paste as a new layer (Ctrl+Shift+V). 3. On the Image menu, click Canvas Size. 4. In the Canvas Size dialog box: a. Clear the "Maintain aspect ratio" checkbox. b. Decide how thick (in pixels) you want your border to be. Multiply that number by 2, then add it to the numbers in the Width and Height boxes. (For example, if you want a 1-pixel border, add 2 to Width and Height.) c. In the Anchor section, click the diagram's middle box to keep your image centered. d. Click OK. 5. In the Layers window, click "Background" to switch to that layer. (You don't have to hide Layer 2, which contains your image.) 6. Select the Fill tool, then click your image. Your border appears. 7. In the Layers window, select Layer 2, then merge it with the Background layer (Ctrl+M). 8. Save your image in the format of your choice.

MJW: Nice job! You've "proved" yourself as a master image manipulator.

Actually, I think he's referring to the graphic toolbar, directly beneath the menu bar: ...and you're thinking of the function bar, or whatever it's called, below that. (It's a bit confusing, as the other bar does actually show the word "Tool".) I, too, have often wished I could hide PN's toolbar. I always use menus and shortcut keys, and never bother to click on toolbar buttons (though I realize many people like to do that). Vertical space is often at a premium when working with graphics, especially on portable computers. For that reason, every other graphics app I've seen has let you do things like this. It'd be a real advantage if PN would, too.

Hmm, that's odd—I got an email message saying a user named "chinatea" had posted to this thread. There's nothing here, though. Well, okay. Maybe it's just me, but considering P.N. already "remembers" where you put its windows (Colors, Layers, History, etc.), I don't understand why it can't do the same with its Adjustments and Effects boxes. You trust users not to "lose" the windows, right? So what would the difference be, other than not having to move the Adjustments/Effects boxes out of the way every time you used them? How could it possibly "confuse" users for the boxes to open where they, the users, had moved and used them? I'm not talking about settings, options menus, or any of that... I'm just talking about standard behavior with users' convenience in mind—all users, not just so-called "power users".