But honestly, spend a weekend learning Gimp. It's a pain, yes I know, but I'm really glad that I did. The official tutorials are wonderful. You'll be able to do so much more, and do it so much better, and even a bit quicker than you could in Paint.NET that you'll wind up preferring Gimp even in Windows.
Just be sure to use single-window mode.
GDI actually exists for Linux (at least for Mono), but it's not really something you want to use in production.
Windows Forms doesn't exist (yet). IIRC that's what paint.net uses, so you're out of luck.
Third party toolkits like GTK#, wx.NET or QtSharp will work on both OSes.
https://blog.getpaint.net/2007/12/04/freeware-authors-beware...
I understand why the author is upset, but his cure is worse than the disease.
So, what is upsetting you here, really?
That has not been true in my 15 years of Linux. Look at bitsync, rstudio, or other major programs. Arch Linux must build off of the source so that isn't a fair comparison you are on a totally different system (port).
EDIT: Here is the one page of documentation to push out deba nd rpm on mono projects. http://www.mono-project.com/docs/getting-started/install/lin...
I have seen electron applications (pinta isn't built on electron but mono) and in the same way ONLY Ubuntu is advertised under Linux. The ability to automatically build Linux formats is built into the framework and still don't add RPM.
Linux: AppImage, deb, rpm, freebsd, pacman, p5p, apk.
Still other eclectron applications do the same thing and ONLY provide Ubuntu and not provide the Deb or RPM with source.
Look at the download page it says Linux and directly under it has a Ubuntu Logo and a ppa link. When I down load any of my commercial or major software there is always a RPM and a DEB with a tar.
Linux Support = RPM (The official Linux Foundation package) DEB and Source.
I use OpenSUSE and they have awesome build service that allows people to build packages for SUSE but also RPM, Arch and anyone else you want to add.
In my time with Linux using anything other than your distributions package tools is an exception and extremely rare. You might do that for - say - bitsync, because it is proprietary. Your distribution cannot use the same 'grab sources, compile against our current libraries and package it up' process.
pinta instead follows the normal process. You install it by using your package tools. Your distributions created binary packages for you already, hosted on their infrastructure.
Heck, even on Ubuntu you'd probably apt-get install pinta and get a different (Ubuntu provided) package instead.
Check http://www.gimp.org/downloads/ and see what they do if you want to download their software (they tell you that your distribution is in charge and even mention why that is usually a good idea).
PPAs and OBS offer ways to build packages, yes. But again, that's the exception - most of your packages aren't coming from there.
The Arch Build System is a ports-like system for building and packaging software from source code. While pacman is the specialized Arch tool for binary package management (including packages built with the ABS), ABS is a collection of tools for compiling source into installable .pkg.tar.xz packages.
I have built and maintained packages for RPM and for Arch. They are different and that is the reason why in electron export Arch has a different system then deb or rpm.
> In my time with Linux using anything other than your distributions package tools is an exception and extremely rare.
That is your experience. Most Ubuntu and Arch people use AUR or ppa all the time. If I want the preview of RStudio (Open sourced and in my official repos) I down load and use the RPM. I do this all the time. If I want anything that was recently released I need to use the RPM and not the packages provided by my disto including rolling releases.
> Check http://www.gimp.org/downloads/ and see what they do if you want to download their software (they tell you that your distribution is in charge and even mention why that is usually a good idea).
I don't find much with the Gimp project to show as a positive example for other applications to follow.
> PPAs and OBS offer ways to build packages, yes. But again, that's the exception - most of your packages aren't coming from there.
Once again that isn't my experience and that is open to other people's needs. If you use AUR you also are not getting your packages from your official repos. Build a AUR and you will see. https://wiki.archlinux.org/index.php/Arch_User_Repository
AUR are awesome BECAUSE it works with the source files in a port system. The only difference between a AUR and a binary you get from pacman is that it was compiled for you to skip the step of downloading the source and compile like you do in AUR.
Yes, ABS is used to build binary Arch Linux packages from sources. But that's unrelated. Debian, Ubuntu, Fedora, RedHat, Suse - all of these do the same: Grab the sources, build binary packages. Whether you're using ABS or build rpms from a specfile doesn't matter for the discussion about upstream's (lack of!) responsibility to provide binary packages for random distributions.
So yes .. Arch is, for the sake of this discussion, working exactly like Debian/Fedora/Suse etc: The distribution (pick any from that list or any major distribution you can come up with) takes the pinta sources and builds a package from that. The end user installs a (binary) package using the distribution's package management facilities without ever touching the pinta source. The package comes directly from the distribution's infrastructure and not pinta's project site.
I still stand by the need to provide RPM, Deb and Source for your project to be called Linux supported. Also Ubunutu does not equal Linux.
Here is VS Code as an example https://code.visualstudio.com/?utm_expid=101350005-28.R1T8Fs...
This isn't provide distro specific packages this is provide the one extra file over macOS and Windows.
Also this is for the health of the Linux environment.
That is why we have RPM and Deb they work for MANY distros and if your outside that then the source is there for aa build. One day appimage, flatpak or Snap will make this easier.
Yes, the formats are shared (say, RPM for Fedora, RedHat, Suse). But the resulting binaries aren't (usually, automatically - you might get lucky of course) compatible.
The whole point of distributions is to build a system. Fedora and Suse are on different schedules, make different decisions about updates, might run different versions of the libraries your package (here: pinta) depends upon.
Your RPM file often isn't even usable between different releases of the same distribution. So just adding a random RPM wouldn't make sense. You brought up OBS elsewhere: One of the major reasons that thing exists is so that you can build packages .. for a list of target platforms. OBS is a service that uses a build recipe and upstream sources (pintas tarball) to spit out binary packages for various different environments and formats.
So one additional RPM file wouldn't do the trick here.
In the old dasy of Linux their would be a lot of issues but presently RPM and Deb works like a charm fro my uses.
I am hoping for appimage of flatpak to take over but for now RPM is my life blood to get things working.
If it is a niche program that won't be on the repos or it is updated frequently RPM is a very viable system.
RPMs don't work in a vacuum. Unless you bundle a statically built thing or something trivial (say .. a shell script) you reference dependencies. Those change between environments.
32bit/64bit machines differ. Ubuntu vs. Debian, Suse vs. Fedora. Builds for current versions of Ubuntu might not/will not work on older ones. You can only provide a (guaranteed to be working) rpm by having one per combination here, a la 'This is for Ubuntu FunnyName 32bit'. You understand that this explodes in complexity quite easily and quite fast.
Now, you're bringing up exceptions again and again (your system is 99% Suse provided packages I'd bet and you have less than a handful applications that you install manually. High profile apps maybe, but still: A few, compared to your distribution's packages).
I can't explain each and every case, but let's look at VS Code: They offer an RPM. That's true. But that's a 50MB file that depends on .. nothing, really. glibc and /bin/sh. All static. You're downloading a zip, more or less. Possible, but wasteful and not common. Download Atom and VS Code and you download Electron twice. You're also ignoring most of rpm's feature set here. This is not a good example for 'providing an RPM' (again, a tar.gz might provide ~the same~ if you ignore that this puts a .desktop file in the right place to create a shortcut to launch this thing. Extracting this to ~/opt for example would give you 99% of what this RPM package does).
For ~normal~ projects, providing packages is just not feasible and bundling projects into coherent ... packages (ahahaha) is what distributions are for, really. Debian knows that it patched library X and all projects using that library might need to be bumped as well. Debian can rebuild their own packages at the same time. Upstream projects cannot follow every distribution and update their '32bit Debian Jessy' build in a timely manner after the distribution changed some parts of their system.
appimage/flatpak etc. are basically doing what your VS Code example did again: A bundle of everything. 'Portable apps' in the Windows world. OS X bundles. In my world that's really a bad trade-off, although I understand the appeal in terms of simplicity. I personally feel that this comes with a high(er) risk for security issues and don't like the wasted space.
Back to pinta: They provide a _real_ package (actually they don't provide any binary package, they just link to a PPA they maintain, probably because they actively use that themselves?) with dependencies. Not a lot, but they actually define a real package. Not a complete bundle with a random file extension like VS Code. For pinta it would be more effort to create RPMs and the benefits aren't clear at all (just zypper install pinta or whatever you do on Suse).
Please ignore the file extension. RPM isn't RPM in these cases. Please don't claim that pinta mixes up Linux and Ubuntu. There's no reason to get worked up ("I hate it when they do this") about this. They handle this the normal way, the standard way. I haven't seen Suse in action for ages, but I suppose you're either using KDE (likely) or Gnome (maybe). Both don't even offer any binaries (for Linux) as far as I'm aware.
vim doesn't offer RPMs either..
(On a side note: VS Code is completely available in the open for some time so it could be built the ~normal~ way using shared libraries for dependencies. Bittorrent Sync will always be a problem though)
I get "worked up" when the only thing offered is a ppa and a source :)
Back in 2006, when I switched to Ubuntu, I used to be the one complaining that developers pretended Redhat = Linux. If I had to choose, I'd pick .deb over .rpm any day.
FWIW, Gentoo offers Pinta in the portage tree:
* media-gfx/pinta
Available versions: 1.6-r2 **9999
Homepage: http://pinta-project.com
Description: Simple Painting for Gtk
it's also on pacman https://www.archlinux.org/packages/community/any/pinta/
Beyond that it's closed source, so it would require the Paint.NET developers to port it to Linux.
Wine is probably going to be your best bet.
There are only some open-source libraries but they are very new.
Being lightweight, quick to start with just the essential features is what I appreciate in both.
It's just that for my simple uses (stitching bitmaps together, resizing, getting color values, pixel-perfect alignment, working with multiple buffers, turning toolbars on/off, editing in layers) Pinta feels much clumsier than its big brother.
Let Krita be your new friend. https://krita.org/en/
I use four graphics tools in Linux.
1) Inkscape (Vector paint program) I also use it on Windows though I have a Adobe license
2) Gimp (My go to raster image editor)
3) Krita my go to paint program and not really for raster image editing
4) Aftershot Pro - My raw image and editing tool for quick photo edits
Krita is more comparable to Corel Paint then to Photoshop or Gimp.
• It's more packages I need to download. Doubly annoying because 95% of the packages are just "thin wrapper around foo, because we're too hipster to use libraries directly like peasants".
• It installs system-wide services I have to disable/mask just so other programs don't mistakenly use them because they think I run KDE and they have to integrate into it.
• Oh wait, I can't disable some of these, because Krita itself needs them and now I need to figure out how to make them play nice with my desktop aaaaaarggghhhh
"Number of packages" is not a very meaningful metric. The combined filesize isn't that large (not by the standards of an image editor anyway), and under any modern package manager installing a package with dependencies is no harder than installing one without.
> It installs system-wide services I have to disable/mask just so other programs don't mistakenly use them because they think I run KDE and they have to integrate into it.
Really? KDE tends to be a well-behaved crossplatform citizen IME (unlike Gnome) and not rely on anything system-wide. (There was some horribly ill-advised semantic nonsense in KDE 4, but I don't think it ever affected Krita).
But I can't agree on the first one.
I have not checked what these exact thin wrappers are, but most of the time thin wrappers are really useful for testing and switching to another library without being tangled in the old one.
It pretty much follow the "D" (Dependency inversion principle) in the S.O.L.I.D. principles: "Depend upon Abstractions. Do not depend upon concretions.”.
Again, I have not checked the KDE libs you talk about, so I'm assuming this is what these wrappers are used for.
(Source : https://en.wikipedia.org/wiki/Dependency_inversion_principle & https://en.wikipedia.org/wiki/SOLID_(object-oriented_design) )
It's worth taking another look if that was something that put you off in the past.
75 MB appimage download then! https://krita.org/en/item/krita-3-0-released/