Slashdot Mirror
Here's What 2019 Holds For Paint.NET (betanews.com)
The developer of the popular image editing tool Paint.NET, Rick Brewster, has shared his vision of what the coming year holds for his software. The 2019 roadmap for Paint.NET is an exciting one, promising migration to .NET Core, support for brushes and pressure sensitivity, and an expanded plugin system.
BetaNews: Changes are on the cards for app icons and improved high-DPI support -- something that may be seen as mere aesthetic by some, but important changes by others. Switching to .NET Core could have big implications for the software, as Brewter explains: "It's clear that, in the long-term, Paint.NET needs to migrate over to .NET Core. That's where all of the improvements and bug fixes are being made, and it's obvious that the .NET Framework is now in maintenance mode. On the engineering side this is mostly a packaging and deployment puzzle of balancing download size amongst several other variables. My initial estimations shows that the download size for Paint.NET could balloon from ~7.5MB (today) to north of 40MB if .NET Core is packaged 'locally'. That's a big sticker shock... but it may just be necessary."
And, for those who're interested: the move to .NET Core will finally enable a truly portable version of Paint.NET since. Proposals for better DDS support and brushes and pressure sensitivity will be welcomed by digital artists, and there can be few users who are not excited at the prospect of an expanded plugin system.
And, for those who're interested: the move to .NET Core will finally enable a truly portable version of Paint.NET since. Proposals for better DDS support and brushes and pressure sensitivity will be welcomed by digital artists, and there can be few users who are not excited at the prospect of an expanded plugin system.
satisfying everyone's creative needs since Windows 1.0
You're using Windows? You think GMP's UI is terrible? You don't need all its features?
Why would I prefer to download and install this over GIMP?
Just askin
I can't tell you what you prefer. But I can point you at a comparison site so you can make your own decision (the Paint.Net vs Gimp is about 2/3 of the way down)
http://fixthephoto.com/paint-n...
I am Slashdot. Are you Slashdot as well?
The one to buy is Affinity Photo if you can't afford Photoshop+Lightroom.
For design, Xara Photo and Graphics editor.
Paint.net is just a toy.
Minor nitpick .. Affinity Photos is a Photoshop replacement, not a Lightroom replacement. While Lightroom has a subset of Photoshop editing tools, it also has Digital Asset Management tools, something that Photoshop and Affinity Photo don't really have (Although Affinity keeps dropping hints that they'll have DAM tools sometime)
And while I can't vouch for it Affinity's Designer looks pretty spiffy for design work.
I am Slashdot. Are you Slashdot as well?
THE single worst program I think, no, definitely know, I have ever used.
Oh come on now, have you ever used Blender? That UI would give the GIMP a run for its money.
I am Slashdot. Are you Slashdot as well?
I have used Paint.NET for picture editing for over 10 years now, starting when it was a WSU project when Rick Brewster was a Microsoft mentored student there. I support a number of websites, and have a family photo archive. Paint.NET is awesome and I can do pretty much anything I need to do with it. The simple stuff of course, rotating, cropping, adding text or lines or fill, fixing minor photo errors, getting a bit creative. And now and again a few more advanced things like "photoshopping" someone into a photo is fairly straightforward. I am deeply grateful for Rick Brewster and all his work on this. And I am thrilled he has plans far into the future for Paint.NET.
Blenders problem was that it was a inhouse 3D editing tool intended for polygonal editing.
So what was Blender 2.49 good at? Using hotkeys to edit models. Using textures to modify models. Modifying models.
It had enough tools to do primitive animation and physics, but not well presented UI to make the USER use those features.
And if you used 2.49 you know that the internal render is crap, but the user interface is atrocious.
Hence 2.50 was a eventually, where a massive project would try to make everything in the suite as impressive as the raw 3D editing was. And going from 2.49, to the beta, to cycles, to whatever the last version i used: I would say their success should be held to unrestrained clapping and cheering.
The key remaining problem is that Blender is now a "Advanced 3D package", where the less primary features such as animations still has a terrible UI. But advanced users can't tell that because they have learned it, and gotten used to the quirks. This extends to rendering, physics, and all other tools as well.
I hope since they used it they finally added a direct selector to texture painting, instead of randomly having one of 3 possibly windows having a non visible selector.
Microsoft have rewritten the .NET Framework and made it cross-platform. Do you think that's a bad thing? Should they carry on putting loads of effort into the slower Windows-only version?
Paint.NET is standalone software. You're thinking of the Paint program that comes with Windows.
Irony: Agile development has too much intertia to be abandoned now.
Readers like you stopped submitting things of interest to you and started relying on others. Other people came with other interests. A news aggregator like Slashdot is nothing more than the will of its readers. You want to change this?
Click Here
I don't get the Core hype. It's supposed to be more cross-platform, such as running on Linux and Android, but for typical business apps, what does it give one besides migration headaches from pre-core?
The industry is sorely missing a desktop-friendly GUI standard for productivity/CRUD applications. HTML/JS/CSS has sucked for that. You can get HTML+ to act like a real desktop with lots of blood, sweat, and tears, but why does it have to be that way? Billions are wasted using UI rocket science on what should be bicycle science.
Java applets tried to solve that, but Java tried to be an entire OS, making it bloated and full of security holes. A standard should focus on GUI's and only GUI's, offloading as much work to the server as possible to keep the client & standard simple.
Make it coordinate-based on the client-side with any "auto-flow" being calculated on the server. Client-side layout auto-flow is probably THE biggest mistake of the HTML stack (except maybe missing common GUI widgets). The client can send its dimensions or size preferences to the server, and the server can then auto-flow placement as needed, and send simple x,y,z coordinates to the client ("z" being the panel overlay level.). People would also have a choice of layout engines, since they are on the server, not the browser.
Controlling the layout is why PDF is still common. People can't stand it when HTML browsers butcher their layout plans and intent. "Autoflow this, Tim Burner Lee!"
Table-ized A.I.
Paint 3D- what Microsoft did because Paint wasn't awful enough.
Paint.NET- 3rd party freeware that fixes both.
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
I don't get the Core hype. It's supposed to be more cross-platform, such as running on Linux and Android, but for typical business apps, what does it give one besides migration headaches from pre-core?
It lets you run your server software on a Linux cluster in the cloud. That's basically it.
"First they came for the slanderers and i said nothing."
A couple options. For C++ folks there's Qt. You can build UIs from 99% the same code base for every platform.
.NET core. When I try to do something simple like file I/O and there's no google-able easy path ready it just seems worthless.
It's been a while since I checked out Java GUIs, but you can make them.
Most developers are inclined to more broadly used technologies, e.g. like a web UI. React is the hot tamale at the moment. If you need a true think client app you can do electron.
There are some mold and oldy options too like Tcl/Tk that have cross-platform GUI options.
I'm not the biggest fan of
Hell, I use Gimp. It's not experienced friendly either.
The most interesting part of this is the statements about the .NET Framework. I need to look at the links he posted and really digest them. I suspect Paint.NET is pretty heavily tied to Windows right now, and he mentions COM and GDI+ which seems to confirm it. But I've been under the assumption that if you are targeting Windows, you build against the .NET Framework it is already preinstalled and optimized for that machine. If you are targeting cross-platform, then target .NET Standard and compile against the full framework for Windows machines, and the Core framework for non-Windows machines that won't already have the full framework installed. The idea that .NET Core is "superior" to the .NET Framework is new to me. I suppose just compiling against the .NET Core framework only is more consistent than using .NET Framework on Windows and .NET Core on everything else?
And this time explain what it is and why I, as a user of a paint program, should care about .NET Core?
“Common sense is not so common.” — Voltaire
The industry is sorely missing a desktop-friendly GUI standard for productivity/CRUD applications. HTML/JS/CSS has sucked for that.
You already have Qt and Python, as long as Microsoft is pushing C#, Apple is doing Swift and Google Java-ish I don't see how you'd get more unified. I suspect the future for that kind of apps is Electron or something like it. I don't know what it's like to work with but the results like Discord and Visual Studio Code are pretty good. Remember Javascript won over ActiveX, Java applets and Flash so it's not going anywhere. The native platforms are backed by billion dollar companies. What's left for middleware nobody really wants to pay for? The Qt Company had 37 million Euro in sales last year and most of that is professional consulting where they develop custom solutions, the commercial value of just the framework is much less. Like Microsoft/Apple/Google could buy it with loose pocket change but nobody wants it. It needs something to piggyback on...
Live today, because you never know what tomorrow brings
Why are you tying it to a programming language (Python)? The standard should not be tied to a particular programming language. Past attempts keep making these mistakes:
1) Ties it to a specific programming language or OS
2) Packs in crap not related to UI's: EMACS-syndrome. That makes something too hard to keep up-to-date/plugged.
3) Uses a binary protocol instead of text-based
4) Proprietary
5) Designed for LAN's, not HTTP (like X-window)
6) Relies too much on DOM/CSS, which is screwy because it wasn't meant for desktop GUI's.
7) Relies on client to adjust or re-format flow/placement. This makes the client too fat (#2), and inconsistent as different versions/brands will flow different, making testing a bear. The server can adjust spacing based on client size preferences so as to not bloat & buggify the client with this task.
If Electron can get most the bugs and security holes out of it and it shows to be time-proven, then perhaps it can fill that role. In the past for similar tools, one had to keep upgrading the local JavaScript libraries to stay compatible with browser releases/changes.
Largely because Flash and ActiveX proved full of security holes, similar to Java Applets (see #2). JavaScript/DOM is merely a consolation prize; it's still not a GUI standard itself, and sucks when it tries to be.
This just requires old-fashioned thoughtful parsimony: put in the standard what's needed and ONLY what's needed for GUI's. Shift as much to the server as possible to keep the client lean, mean, clean, and focused on one job.
Table-ized A.I.
It's being developed more slowly than .NET Core is as it's far more widely installed and changes that are being made in Core are not necessarily going to be applied to the framework as they might break things. It's not being abandoned but Core is the future.
The pace of improvements slowed...until 2018, when they finally finished integrating babl and gegl with the UI. This was a massive effort, and side issues were put on hold until the work was complete, because without it, The Gimp could no longer remain competitive. However, the release of v2.10 back in April, which was a massive improvement over the 2.8 series, meant that they could finally turn their attention back to features. (Not counting all the ones which magically appeared once gegl was accessible through the UI.)