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.

Comments

Re:Don't get, please explain

[scumdamn]

You're using Windows? You think GMP's UI is terrible? You don't need all its features?

Re:UI Framework

[Tablizer]

You already have Qt and Python,

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.

Remember Javascript won over ActiveX, Java applets and Flash so it's not going anywhere.

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.