I have never ever used an appimage before until just now.
Earlier today, I saw on Phoronix that Krita had a new beta version.
So I went to their website, clicked on nightly build and could not find a beta, but did find an alpha. I downloaded the Linux version which was an appimage.
I went to the Fedora Wiki about appimages and followed the 3 step guide to using appimages and was surprised how simple it was.
Krita 4.4 alpha works nominally on Fedora. so if there is a beta somewhere, then I guess it would too.
In order to try this new version of Krita,
one must understand the basic file system layout in Fedora which in my case is: /david/Downloads/krita4.4.appimage
use cd command in terminal to change to Downloads
In my case, that was as simple as: $ cd Downloads
next easy step ( after the $ in terminal ) type chmod +x krita-4.4.0-alpha-x86_64.appimage
( you can cut and paste the file name to simplify that, as it has some extra stuff in it )
Exit terminal, and go back to Files
Just double-click on the Krita appimage file in Files afterwards.
Please let me know if there is a simpler way. I imagine you might want to move it from Downloads directory to a temporary directory or an custom directory that you created for appimages ??
David Locklear
On 2020-09-23 01:23, David wrote:
one must understand the basic file system layout in Fedora which in my case is: /david/Downloads/krita4.4.appimage
Your system isn't really configured like that, is it?
The selinux contexts of your files are going to be all wrong.
I don't even think you could do a GUI login with your home directory set to /david.
Mr. Greshko,
Again, thank you very much for pointing out my lack of understanding things.
I was only trying to simplify the explanation, that in terminal, I only needed to move to the Downloads folder with one simple command and did not have to use sudo, nor go to the home directory
Someone, please feel free to post a correctly worded version of what I was trying to say.
Also, I already had Krita installed, I think as a flatpak. So did installing another ersion of Krita as an appimage mess up anything.
And will this appimage version automatically update in dnf ?
One more question,
what other clients would be good ones to try as a beta or rc as an appimage ?
Is "clients" the right word ?
I found most of the information I was looking for
There is allegedly an "appimageupdate" client that a user can download, but the recommended practice is to just install a different version of the specific appimage, such as Krita, and then after testing it, delete the one that you do not want to keep.
And it does not hurt anything to keep both.
And there is something called "Firejail," allowing a user to run the appimage in a sandbox. I have NOT yet researched that topic.
Again, feel free to correct me.
I think it would help a newbie, if a distro shipped with an appimage directory and a tiny game like "2048," and explain what all the hoopla is about. The newbie could then delete the directory, if they wish. Or the question could be asked during installation of the distro.
Please forgive my ignorance on this subject
The correct link for the new beta version of Krita, can be found at
https://krita.org/en/item/first-beta-out-for-krita-4-4/ https://krita.org/en/item/first-beta-out-for-krita-4-4/
I downloaded the appimage a few minutes ago, and put it in a new directory called "AppImages."
In addition, there is a plug-in that you can also run, but that is all above my paygrade. ( See G'Mic for Krita ).
https://docs.krita.org/en/reference_manual/preferences/g_mic_settings.html
In the link below, is a screenshot of krita 4.4. beta working nominally in Gnome 3.38 ( using my Rawhide install with custom wallpaper )
https://www.dropbox.com/s/tpiwz1cep2r640b/Screenshot_Rawhide_Krita.png?dl=0
Disclaimer: I had no earthly idea what the "chmod" command did until about an hour ago. I have been using Linux a little over three years for simple household task and my hobby-business.
I did try to run this from terminal and got wayland / gnome area messages and that a python file was missing, but I did not get that when I double-clicked on it in in Gnome Files
At the present moment, I only have doodling experience with GIMP and Krita as shown in the screenshot. But I once did a couple of real drawings back in 1993 ( Microsoft had a drawing tool in Word 6.0 in 1993, if that rings a bell with anybody ), and I was proficient with AutoCAD 12 back in the mid 1990's.
So here is my next question:
Do some appimages contain proprietary blobs. If so, that would ruffle some feathers, if Fedora users recommended those appimages. Is that right ? Or does that sort of fall into the same category as installing third-party repos ??
David Locklear
On Tue, 2020-09-22 at 22:20 -0500, David wrote:
Do some appimages contain proprietary blobs.
Dunno, but I would not be surprised.
does that sort of fall into the same category as installing third- party repos ??
If you didn't install something from the Fedora repos, it *is* external. Whether that be from another repo, or just a standalone download. It comes to the same thing:
The problems with any external file/package are that they may not fit in with the rest of your installation (every distribution of Linux is different in some way), and *you* will have to fix the problem, it's not going to be solved by something/someone else.
Compare that to installing things from the usual repos: It's debugged by everyone using the system. When you install something that needs extra files, the system sorts that out for you. And it can do the converse if you decide to uninstall something. And, as a general rule, you're only going to find compatible packages in the Fedora repos. You're highly unlikely to find a package that cannot be used within the repo, well not in the general repo, there may well be things in testing that are not ready for use *yet*.
On 2020-09-23 13:19, Tim via users wrote:
And, as a general rule, you're only going to find compatible packages in the Fedora repos. You're highly unlikely to find a package that cannot be used within the repo, well not in the general repo, there may well be things in testing that are not ready for use *yet*.
And, FWIW and IMO, there is no point in grabbing Alpha/Beta appimage/flatpak versions of software and reporting one's experience on this list. That feedback needs to go to the authors. This is, again IMO, especially true for software than is normally released in the default repos.
If a greater number of people started to do this, the list would soon become cluttered.
On Wed, 2020-09-23 at 14:17 +0800, Ed Greshko wrote:
And, FWIW and IMO, there is no point in grabbing Alpha/Beta appimage/flatpak versions of software and reporting one's experience on this list. That feedback needs to go to the authors. This is, again IMO, especially true for software than is normally released in the default repos.
If a greater number of people started to do this, the list would soon become cluttered.
I wholeheartedly agree that debugging correspondence needs to be in the appropriate arena.
Also, unless you're able to do what's required of debugging (being able to fix things yourself, or making useful reports, and following technical instructions), people should really steer clear of test packages of applications, maybe even external apps, too.
Sure, if you're using *general* release packages, and you want to discuss problems on *this* list for guidance, that's the right thing to do.
If you want to get into debugging, my suggestion would be *first* get used to the general releases, that work. Then, when you're familiar with how things are supposed to work, you've got background for delving deeper.
Despite my decades of using computers, I don't want to get into nitty gritty debugging. It's too time-consuming and irritating, and some programmers are too weird to even want to deal with. I just want to *use* the computer. Not endlessly fiddle with it.
-
David -
Ed Greshko -
Tim