This idea was floated in our management chat and we want to know what you think! Please do share.
8 Likes
Good idea, I would be happy!
I first time installed an appimage of Rawtherapee during last weeks and enjoyed the ease of it.
yes, absolutely
Yes please
We had GitHub actions build the appimage of the master branch for sometime now. I think keeping a release version available is a good idea. I would just not call it an official appimage. Maybe only keep it in a GitHub action (a release action).
I donāt know whether you should be releasing one, but I wonāt be using it.
- I was very happy to test with it (keeping the official flatpak on 4.6)
- I can see a definite benefit when somebody does not have flatpak. App image is very easy to test (from a user point of view)
- Hopefully it wonāt affect the official flatpak existence.
1 Like
There is no āofficialā flatpak, the flatpak is maintained by the community. The project doesnāt currently distribute any binaries for Linux, only source 
It is very much appreciated!
Using Ubuntu I very much prefer debian packages, cleanly integrated into the OS package system, or building the application myself from source. My experiences with AppImage, flatpack, snap ā¦ are decidedly negative. My vote goes against AppImage, at least I would never use it.
I try to avoid using appimage, though the Digikam ones I have used worked without problems. With what we see here though, appimage seems a better choice than flatpak or snap (e.g. sandboxing is optional in appimage).
Of course, ānativeā packages are the best solution. They also take the most man hours to set up and maintain, given the number of distributions and versions. And you need enough people to cover at least the important distributions. Hard to do with a small group.
So if the development team wants to provide a binary package in addition to the source, appimage may be the best choice. (It may be less āsecureā, but how important is that in practice for a program like darktable?)
2 Likes
Iād say itād be a good idea!
I suspect the majority here are catered for by their respective distributions, but if you think it would help to spread DT more widely, then I would go for it.
In the past I used KDE Neon. And at the end of the release circle I often had problems to get actual packages for it, because itās based on the LTS version of Ubuntu.
Even so I changed my distribution to a rolling one and always prefer to get the (deb) packages which are delivered over the repositories, I really appreciate appimages. They are an easy way to get actual or not in the repos of your distribution offered packages, without the need to install all the flatpak stuff for just one or two applications.
2 Likes
I find AppImages easy to use (if they are packaged well, so no outside dependencies). Since thereās a 1:1 relationship between āpackageā and āexecutableā (they are the same file), installing and removing them is not a hurdle. I hate āsnapā (slow start-up, sandboxing issues even from official sources). Even flatpak is harder to use (e.g. launching an app from the flatpak is done using flatpak run some.package.someApp instead of imply someApp). Of course there are launcher icons etc., but for darktable we often need people to run with some diagnostic option, so making the command-line as uncomplicated as possible is important.
5 Likes
To those active on rolling distributions, building themselves, enjoying deb resources etc, great, but pls remember there are those of us on e.g. LTS ubuntu where itās hard or impossible to build the latest DT. Iāve used flatpak, it works, but I think appimage is better. After all, itās just providing a binary to run on your OS - what is more basic and natural than that!?
5 Likes
+1 from me. On my main PC I currently build from source but when I need it quickly somewhere else (at work, laptop of my wife, etc.), having an appimage would be very convenient.
Is there any notable performance difference between locally build and appimage? If not, I might even switch on my main PC.
There is one more thing to consider here: an AppImage might be useful for people needing support for the most recent Canon models. Most distros will not ship the latest āsnapshotā of LibRaw, but the (now aged) 0.21.2 stable release version which stops at EOS R7 & R10.
2 Likes
Thatā s not necessarily true. There probably will be a version of darktable in the official repositories, true.
I know that with OpenSUse Leap, programs like darktable are not updated in the official repositories (OBS are not official distribution repositories), or only when there are security issues. New versions of libraries are at least as problematic, and new libraries are out. (Leap has 4.2.0 as the officially provided dt version)
Thatās not a bad thing in itself, just unpleasant with programs in rapid development. So an appimage for each new version would be useful for those who donāt have access to an updated oOBS repository, or donāt like using them, and who canāt or donāt want to compile dt themselves.
1 Like
Iām just using the appimage of DT 4.8. Works nicely.
Itās not perfect.
One issue is that the start is slowed down by building the OpenCL program(s) each time.
Another issues seems to be the value of WM_CLASS.
The command
xprop WM_CLASS
returns
WM_CLASS(STRING) = āAppRun.wrappedā, āAppRun.wrappedā
I guess the result should be something like
WM_CLASS(STRING) = ādarktableā, ādarktableā