Make shutter available on flathub

[TNTBOMBOM]

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)

One app = one file = super simple for users: just download one AppImage file, make it executable, and run

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

Optional binary delta updates, e.g., for continuous builds (only download the binary diff) using AppImageUpdate

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.

Can double as a self-extracting compressed archive with the --appimage-extract parameter

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:

• Upstream ticket
• Ricochet-Refresh
• Electrum
  ..etc

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!

[Photon89]

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!

[vadi2]

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.

[JakobDev]

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.

ShutterFlatpak.zip

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.

[Photon89]

@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?

[JakobDev]

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.

[Photon89]

I don't know either, unfortunately. Maybe this and links therein help somehow: flathub/com.github.donadigo.appeditor#18

[Photon89]

@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.

[JakobDev]

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

[Photon89]

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.

[JakobDev]

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.

[Photon89]

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.

[JakobDev]

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.

[Photon89]

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!

[Photon89]

So, it currently:

• checks for plugins each launch
• discards screenshots taken in a previous session
• cannot do "open with..."
• has no support for profiles
• crashes when trying to open the context menu

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.

[JakobDev]

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.

[Photon89]

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: #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.

[JakobDev]

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.

[Photon89]

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?

[JakobDev]

Any News on this?

[Photon89]

No, we are stuck with #492, I fear...

[JakobDev]

Maybe we could use the XDGStandard only if running as Flatpak?

[Photon89]

I think, it is equally problematic to implement in a Flatpak environment and in general...

[TNTBOMBOM]

No, we are stuck with #492, I fear...

Seems that ticket closed as devs doesnt know how to fix it?

[Photon89]

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!