Open TNTBOMBOM opened 1 year ago
Unfortunately, none of the team has experience with creating both Flatpaks and AppImages, but we'll gladly accept PRs and/or provide any support if somebody tackles this!
I don't see permissions being mentioned anywhere - fairly certain that if we make a genetic flatpak package without opting into flatpak's permission system, we will get heat for "not having done it right". All this while adapting an application to the permissions is no small feat in itself, on top of packaging for flatpak.
Just something to be mindful of, I'm not saying we shouldn't do it - there's just a lot more than meets the eye. AppImages on the other hand do not burden the developer with this.
I have created a Flatpak. It was more work than I thought. Unfortunately it crashes at the start and I don't know why. Maybe you can take a look at it and see what's going wrong.
I crashes with this message:
qvalue_changed was emitted by widget Gtk3::HScale=HASH(0x56151da78b40)
Can't use an undefined value as an ARRAY reference at /app/bin/shutter line 4956, <DATA> line 19.
Shutter::App::fct_get_program_model() called at /app/bin/shutter line 1377
Shutter::App::STARTUP(Shutter::App=HASH(0x56151d6768c8)) called at /app/lib/perl5/site_perl/5.38.0/x86_64-linux/Glib/Object/Introspection.pm line 67
Glib::Object::Introspection::__ANON__(Shutter::App=HASH(0x56151d6768c8)) called at /app/bin/shutter line 10944
All this while adapting an application to the permissions is no small feat in itself, on top of packaging for flatpak.
It's usually not that hard. In most cases, you don't need to change anything,. But I can't say, if Shutter does some stuff that cause problems.
@JakobDev In the referenced line, the array @$apps
is being processed, which is defined as
my $apps = Glib::IO::AppInfo::get_recommended_for_type('image/png');
So, Shutter checks using GIO which apps are associated with the image/png MIME type. Probably this procedure is problematic in a Flatpak?
I don't know much about this GIO API. Does it need access to the desktop files? Running external Apps from a Flatpak is possible, but not recommend, so this should maybe be disabled.
I don't know either, unfortunately. Maybe this and links therein help somehow: https://github.com/flathub/com.github.donadigo.appeditor/issues/18
@JakobDev
I tried the following, which disables the functionality:
--- /usr/bin/shutter 2023-07-27 14:30:04.512076656 +0200
+++ /usr/bin/shutter_edited 2023-07-27 14:29:38.671888063 +0200
@@ -4950,7 +4950,13 @@
}
#get applications
- my $apps = Glib::IO::AppInfo::get_recommended_for_type('image/png');
+ #my $apps = Glib::IO::AppInfo::get_recommended_for_type('image/png');
+ my $apps = ();
+
+ # we are in a flatpak and $apps is empty
+ unless (defined $apps) {
+ return $model;
+ }
#no apps determined!
unless (scalar @$apps) {
If this works, you would need to apply the patch while building the flatpak, is this possible? As I don't know how to check if we are in a flatpak environment on runtime.
If this works, you would need to apply the patch while building the flatpak, is this possible?
Yes, the Flatpak build files I uploaded already contains patches
As I don't know how to check if we are in a flatpak environment on runtime.
Check if the file /.flatpak-info
exists
Ok, great! Could you try if the patch solves the original problem? If so, I'll try to implement the check such that no patch is necessary.
It stars now and I was able to took a Screenshot, but I haven't done deeper tests. This is my current Manifest: ShutterFlatpak.zip You can built it yourself and test things out.
If you want to built from your local source, replace
- type: archive
archive-type: tar-gzip
url: https://api.github.com/repos/shutter-project/shutter/tarball/v0.99.4
sha256: f260530b50c5bcf9f38206d4bf812186b92c829c8a9724dfc7a4858ffd5df531
with
- type: dir
path: path/to/your/local/directory
One thing you need to do is the use the XDG Base Directories instead of the .shutter
dir in Home.
I tried building it but it tells me
$ flatpak-builder --user --install --force-clean ./build org.shutter_project.Shutter.yaml
error: org.freedesktop.Sdk/x86_64/22.08 not installed
Failed to init: Unable to find sdk org.freedesktop.Sdk version 22.08
Probably a problem on my end as I just installed flatpak and flatpak-builder, never used is before.
You need to install the SDK. Also I recommend d you to use the flatpak version of flatpak-builder. Just run these commands:
# Install everything
flatpak install org.freedesktop.Platform//22.08 org.freedesktop.Sdk//22.08 org.flatpak.Builder
# Build and install
flatpak run org.flatpak.Builder build-dir org.shutter_project.Shutter.yaml --force-clean --install --user
# Run
flatpak run org.shutter_project.Shutter.
The first build may take a while, because it complies the Decencies like Perl from source.
Works, thanks for the instructions! It produces a crash when right clicking though, looks like the same call is being made in other places as well. I'll try to patch it up!
edit: @JakobDev Where can I find the flatpak's installed files? I looked in build-dir/files, but changes therein seem to have no effect.
edit2: Never mind, found it!
So, it currently:
But other than that it works. Unfortunately, the error output was not related to the crash, it shows no errors any more and still crashes. Is there any way to make an app in a flatpak interact with the file system? Looks like most if not all problems originate from the fact that it currently cannot.
Is there any way to make an app in a flatpak interact with the file system?
By default Flatpak Apps only have access to ~/.var/app/$FLATPAK_ID
. The XDG
variables are set to this Directory. It is possible to grant a Flatpak Permission to access more files. You can read more here.
edit2: Never mind, found it!
Please don't edit the files directly. These files will be overwritten by each rebuild. Just change the Mainfest to point to your lcoal development directory as described above and do a rebuild.
You can also open a interactive shell by running:
flatpak run --command=bash org.shutter_project.Shutter
So you can explore how it looks from inside and what you can do.
Please don't edit the files directly. These files will be overwritten by each rebuild. Just change the Mainfest to point to your lcoal development directory as described above and do a rebuild.
Yep, I just wanted to do a quick and dirty test.
By default Flatpak Apps only have access to ~/.var/app/$FLATPAK_ID. The XDG variables are set to this Directory. It is possible to grant a Flatpak Permission to access more files. You can read more here.
Unfortunately, Shutter doesn't use XDG so far: https://github.com/shutter-project/shutter/pull/492
It currently acquires the home folder's location via Glib::get_home_dir
. Is the $FLATPAK_ID
variable accessible via Perl on runtime? In this case, we can let it check whether we are in a flatpak, and if so, set the path accordingly.
Is the
$FLATPAK_ID
variable accessible via Perl on runtime?
It should be available, but I suggest that you use the XDG_DATA_HOME
or XDG_CONFIG_HOME
to get the path. As I said, you can also check if /.flatpak-info
exists to know if you are in a Flatpak.
Well, it seems to be a nontrivial change, in particular, regarding the migration for existing users.
@DarthGandalf @ruzhnikov What is the status with #492 currently?
Any News on this?
No, we are stuck with #492, I fear...
Maybe we could use the XDGStandard only if running as Flatpak?
I think, it is equally problematic to implement in a Flatpak environment and in general...
No, we are stuck with #492, I fear...
Seems that ticket closed as devs doesnt know how to fix it?
The PR has been created by a non team member who created a fork and at some point decided to close the PR after nothing happened for a long time. The team members don't have the time resources to take it further but contributions are welcome!
Description of requested feature:
Make PR for shutter to have it on flathub.
Reasons for adding feature:
I have reviewed ticket #325 and can provide the same reasons along with a few additional advantages and changes. (I will avoid repeating the same benefits and instead focus on the modified ones)
The process is the same for Flathub apps, but the difference lies in the fact that the user needs to visit the Shutter or X website to download the official image. They can't obtain it while using the search functionality in an application manager like Flatpak, where they can search for the tool's name (the tool's name doesn't need to be exact; it can be descriptive, such as "screenshot").
Instead of going to x website, downloading the AppImage, making it executable, and then running it, the user can install Flatpak, add the Flathub repository (which are included by default in Fedora Silverblue, Pop!_OS, and other distributions), and install Shutter.
All of this can be accomplished with a single command, for example, in Debian: (if your distribution doesn't have Flatpak or Flathub added already).
sudo apt install flatpak && flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo && flatpak install flathub org.flatpak.shutter
This is tricky, its not easy as it sound to have your appimages updated to the latest version similar to flatpak (or any app manager generally). you can check how many apps based on appimage having "Yes, can use AppImageUpdate" ticked here.
No need in flatpak case.
Also, there is a known issue with AppImage: If your glibc (which is considered one of the core libraries) has a version that is either lower or higher, it can lead to your app failing to run. Check for examples:
Other than these differences, there are no other advantages to using an AppImage. The only advantage I see is for developers who want to target mainly offline operating systems that have no internet access and do not wish to focus on specific GNU/Linux systems like .deb or .rpm. In this particular case, yes, an AppImage can be beneficial. However, apart from this scenario, there are no additional advantages.
Extra information:
I'm not saying that you should deprecate AppImage and use Flatpak. There is no conflict, and you can use both. However, if you have to choose one, I would recommend Flatpak.
Thx!