NinthDesertDude

That's called magnetic selection, which paint.net currently doesn't support. Gimp will have that feature and you can use it for that job.

All scenarios I could think of passed. I think my .abr file was unsupported. Lets hold conversations in PM or elsewhere so we're not bumping this thread all the time

Can you upload the .abr files you're using?

Thanks for fixing those bugs, Null54. There are a couple more since I git pulled: 1. In subsequent runs, if I have moved or deleted a folder from the custom brush locations that had successfully loaded on the first run, it will crash with DirectoryNotFoundException. 2. It seems that it no longer loads .abr files.

I've drawn many fireballs, but never kept or uploaded them. This is supposed to be a magical fireball (as indicated by purple/blue hues). Thought it looked cool. Added a quick background and called it a day. Done in 1 hour on 11/10/2018. Inspired by the fireball, I decided to make a lightning ball. Done in 6 hours from 11-10 to 11-11 in 2018.

Turn off rotate with mouse (which is off by default), and you can click around without problems. Just clarifying in case you weren't aware and for silent readers. @null54 I pulled your changes, but I got some interesting errors: 1. When settings were moved, my .xml file ended with "settings>ings>" which caused it to crash, We should try...catch and regenerate the file if it fails to de/serialize. 2. Default brushes only load on subsequent runs. 3. On subsequent runs, custom brushes are appended to the first run's brushes, so it's custom brushes, default, custom brushes. No change observed with further runs. 4. The brush I had selected in a previous run is selected, but as brushes load in, the selected brush changes to the last one. All errors reproduced within two consecutive runs and are fully reproducible. Both folder paths are included in my .xml file, so I'll share all those contents in a .zip for you to try and reproduce. Non-reproducible error: - The brushes failed to load after deleting a folder that's listed in custom brushes at one point; clicking crashed because I didn't have a valid bitmap, but I couldn't reproduce the error. Other things I noticed: - Since the brush icon I made was for the list view, I created a 24x24 one that should fit the size of the button. Haven't committed it anywhere yet. - Your changes to the inherited RenderArgs code and undo/redo fixed the long-standing transparency bug for the most part; drawing is still a problem. If you can find the fix for that, I'll be pretty happy.

Awesome for performing migration of stuff from registry, @null54. I was going to add that if you hadn't. You discovered a design choice, actually. I need two points to determine the direction to make the image face, and since I don't track the previous mouse position until you start drawing, I only have one point. In experiments where I did track previous mouse position at all times, I discovered I'd get some bad results because there was almost no space between the two points because I slow down a lot when I start drawing the line. Reducing space between the two points has the interesting effect of reducing the accuracy of the direction of the image, so it was frequently pointed in the wrong direction (slightly, or sometimes substantially).

XML is fine.

I want to support portable mode, so it's a good idea to store in an .ini file or something. I don't think the add folder change will be necessary due to infrequent use, like you say. Thanks again for taking an interest.

Ignore most recent instructions. If you're still unsure about it, choose the line tool or just press O to switch to it. Click and drag to create a line. You'll see four circles on the line; you can drag those to curve the line. Press enter or click away from the line to stop editing it so it becomes part of the picture.

Thanks, I attempted to test the image scaling by calculator and testing and apparently didn't notice it.

Rendering a bitmap from vector? I'm in no hurry . Maybe after everything else and when I feel good about the code being neat and concise, but I wouldn't usually feel that needs incorporation. If I wanted to do it right, I'd want to treat vector-based bitmaps differently so I generate the bitmap when selected or when brush size changes instead of how I use bitmaps. New points: - Maybe, just maybe, vector-based brushes

@Eli Out of scope. If I add a line tool, where do I stop? I don't want to make paint.net inside paint.net I can do it as a separate plugin. @null54 I added a review comment on the PR if you want to look at it.

@welshblue My last message was in response to what seemed to be some confusion about which version was in use. Testing is always useful; I don't have the changes in source code yet and null54 is making a lot of changes, so I'm waiting for him to submit a PR to test it all independently myself. I'll just fix whatever isn't working at that point. Your intermittent testing helps, too, I'm just really busy this week and didn't have a lot of time to contribute yet.

Please note that the versions posted on this thread aren't the official versions, so they'll have bugs, bad bugs and worse on occasion. It's nice to note, though, but it's no measure of failure. Pixey and Welshblue, you are both using a version on this thread; I also tested against the official version and it doesn't have those bugs (phew).

Readers should note that WinForms and WPF in .Net Core 3 will still be Windows-only, so updating to it won't make Paint.NET multi platform.

Resizing to sliderBrushSize.MaxValue for the largest dimension would be a good idea (currently 500). Maybe add the resize function to Utils.cs. We can ignore brushes bigger than 3000 pixels in either direction because it's just nonsense at that point. I say 'either direction' because images are padded to be square so that rotation doesn't skew the image. That's what I get for only testing that the .abr format works. It sounds like @null54 fixed that, so I'll hold tight for a PR. I'll take the listview changes, too.

Since it's hard to read .ABR files in pieces, this becomes the best solution. It also simplifies loading / unloading on demand when everything is in picture files only. I used it on another project with file copy operations until I realized the latter was taking too long, so I'm familiar with the strategy.

We can load all images and ABR files in a background thread and add them in real-time to the brush window, that's a start. Memory usage still increases as we load images, so I'd like to delay loading the images until the user can see the thumbnails in the list view (lazy-loading, or more aptly, load-on-demand). This is how it will work: 1. On a separate thread when the plugin starts, crawl listed directories for .abr files and read the number of images in each .abr file. 2. Add an option to the list view for each image, then add an option for each entry in the .abr files we just read. 3. Options have metadata for: doPersist (true for default brushes), isActive (true for selected brush), filePath, isLoaded.. 4. Find which items are visible in the list view. If !isLoaded && (doPersist || isActive)), load it from the filePath. If !doPersist && !isActive && isLoaded, unload it. 5. When you load and unload images, do it asynchronously and dispose properly. It would be great if you could develop/inform me about reading the number of images in each .abr file, null54.

Thanks for the video. It looks like ordinary lag to me, which should be resolved by better image management when I implement lazy-loading brushes.

Haven't seen it, could you?

I can resolve the issue I mentioned by moving add brushes to a button below the list view, so it'll better separate concerns, improve user UI, and remove the need to solve that issue. The button will be the same width as the list view and might have its own icon. I made sample icons at 64 x 64, but I'll probably go for a smaller version of the gray one. The reason I didn't start off with a button was because it didn't look right with a combo box above it (ah, solving many UI problems at once). The icons, if you're wondering.

Why didn't I think of that? Here I was, ready to write a custom combo box. This is simply a better approach. I appreciate it. Are you talking about how the brush resets when you open the dialog after you use a brush, select browse for additional brushes, cancel browsing, confirm the dialog and run it again? I was just about to say that it doesn't remember the brush in that corner case. I downloaded it half-an-hour after your message. I'd approve this change if you pull my changes for keyboard shortcuts which I made after your previous merges and take a look at the issue I wrote above, which might be what you're talking about. These are useful changes, for sure.

Well you never really did, unless you can't use mouse wheel. This is relevant because right now, Ctrl + R + mouse wheel and Ctrl + A + mouse wheel are the only ways to rotate and change alpha without using a slider.

@welshblue I'm glad you said something, because changes to the keyboard shortcuts will require changing the wiki, which I forgot I wrote. I'm glad you found it useful.