Provide a Flatpak package.

[RokeJulianLockhart]

My rationale is available at https://github.com/safing/portmaster-packaging/issues/43#issue-956312378#:~:text=It%20shall%20allow,to%20support%20this. I am thankful for any assistance.

[Skif-off]

Is this a religious question? Do you have any arguments?
DC does not require any rare components or the most recent versions (that are may not be available in some Linux distributions)...

[RokeJulianLockhart]

#309 (comment)

@Skif-off, my rationale for this proposition is that deployment of .tar archives is not as easy as installation of flatpak packages (from where .flatpakref files have specified). Additionally, if this were to have been installed from distribution-specific – .Deb or .RPM – package repositories, the name of the package could differ, as does frequently occur due to modification of it after initial submission of the package. This means that automation of installation is significantly easier, because the logic is not different for each Linux distribution. Conclusively, deployment is more easy.

Additionally, because I utilize other flatpak packages, I am able to utilize the run-times that have already been installed, rather than installing dependencies which otherwise would not be necessary. Conclusively, although flatpak is useful for abstraction and compartmentalization, it is not necessary, so the resultant package should not be significantly different.

I know not how this proposition is able to be religious, and I doubt that discussion of that attribute shall affect implementation of this. I consequently intend not to ascertain how. Regardless, I intend not to cause argumentation.

[Skif-off]

This is meaning that automation of installation is significantly more easy

This is controversial opinion.

In Debian (and based on it): first version is 0.5.7 (25 Sep 2013), so people suffer 8 years... Or not?
DC has no hard dependencies, also a list of dependencies is very simple and DC is available in many Linux distributions, so, at first glance, no urgency make a Flatpak-package.
And limiting the access to the file system for file managers looks strange.
I don't understand. Or is it just fashionable?

I am not knowing how this proposition is able to be religious

Holy Wars, Flame Wars, Special olympics and other ways for talks and exchange of views/opinions in the Internet. In this case I mean hot heads and "traditional packages vs. Flatpak packages".

[j2969719]

at the moment, portable versions, appimage and obs for native packages for popular distributions are provided for linux. adding flatpak, snap, or whateverhotnewthing to this list can only increase the workload for one active developer.

[gmanny]

This would come in handy on Steam Deck because you lose regularly installed packages when updating the OS there because it uses twin partition setup for updates - they both contain the same OS, on update, one of them is updated and currently active OS partition is swapped to it.

There are ways to disable this behavior, but they are not recommended for general users, so having a Flatpak could be a good idea for these users.

[poiNt3D]

Immutable distros have to rely on containers.

[RokeJulianLockhart]

@soredake, why do you disagree with #309 (comment)? Rather, how? — Immuntable distributions indeed must rely upon containers: Fedora Silverblue and Kinoite's OSTree base system becomes corrupt easily if layers of standard packages are added to it. Additionally, I believe that SteamOS simply expunges them when reinitialized.

[TorrSamaho]

I'm also interested in Flatpak support for Double Commander. To see how much effort this needs, I started to work on a prototype: https://github.com/TorrSamaho/org.doublecmd.Doublecmd

It still has some glaring issues (crashes on exit, displays unintended mount points), but it compiles, installs and runs.

[Skif-off]

displays unintended mount points

Report about this (just run mount and show this mount points) or add PR (see CheckMountEntry in src/platform/udrivewatcher.pas).
Or try Drives blacklist and add a recommendation to use it in the description (if you publish this Flatpak package).

[TorrSamaho]

Thanks for the info! The mount command does not seem to be available inside the flatpak sandbox, but I managed to patch CheckMountEntry to get rid of the unintended mounts points. So far I didn't make a PR since I'm not sure that my workaround is a proper fix: TorrSamaho/io.github.doublecmd.DoubleCommander@491b71a

[TorrSamaho]

Another update: The crash on exit does not seem to be a flatpak problem. If I build the current head of the double commander repo (8a52783) instead of tag v1.1.2, the resulting flatpak doesn't crash on exit anymore.

[alexx2000]

Looks like application ID should be io.github.doublecmd.Doublecmd or better io.github.doublecmd.DoubleCommander.

But really file manager without a full file system access is a strange thing.

[TorrSamaho]

Looks like application ID should be io.github.doublecmd.Doublecmd or better io.github.doublecmd.DoubleCommander.

Thanks for the hint! I'll change the ID accordingly.

But really file manager without a full file system access is a strange thing.

I'd say it depends on what you use it for. For nearly all of my use cases for Double Commander, the file access possible with flatpak is sufficient. Also, KDE's file manager has an official flatpak version: https://flathub.org/apps/org.kde.dolphin

[alexx2000]

I think that DC as file manager should have a maximum file system access --filesystem=host which is possible in the flatpak (many more simple/high level applications at flathub have it). And it should not hide host mount point. Also DC should have gvfs access permissions.

Powerful file manager is a low level system component. So there are many other problems/questions:

1. How file associations work in the flatpak sandbox?
2. How to execute external applications?
3. etc.

[TorrSamaho]

I changed the ID (https://github.com/TorrSamaho/io.github.doublecmd.DoubleCommander), replaced the file permissions with --filesystem=host and unhid the "/run/hosts". This now displays unwanted mounts again, including files (e.g. I have desktopfs-pkgs.txtin my root folder and this is displayed as mount), but I don't have time right now to further look into this. I can also add the gvfs permissions. Do you think --filesystem=xdg-run/gvfs would be the proper permission for this for the Qt version of DC?

How file associations work in the flatpak sandbox?

To open files with their corresponding default tool, one could perhaps use xdg-open from https://github.com/flatpak/flatpak-xdg-utils. AFAIK one is somewhat limited in what one can do with file associations inside the sandbox.

How to execute external applications?

If you want to call an arbitrary external application, flatpak-spawn --host can be used (although that this is more of a workaround than a proper solution).

How to move files into trash?

Using TrashFile() from the org.freedesktop.portal.Trash https://docs.flatpak.org/en/latest/portal-api-reference.html#gdbus-method-org-freedesktop-portal-Trash.TrashFile.

So, numerous features certainly require some changes in DC to go through the corresponding portals.

[TorrSamaho]

I made some changes. DC does not show garbage mounts anymore. Also DC use xdg-open now.

Great, thanks! This both seems to work nicely for me with your changes.

Trash theoretically should work without changes.

This does not work on my end yet. When I try to delete a file with DC in flatpak, I get the error: "Can not delete ... to trash! Delete directly?"

If you want to call an arbitrary external application, flatpak-spawn --host

OK, then --talk-name=org.freedesktop.Flatpak permission also needed.

Added. With this added, I could configure my external editor by setting path to flatpak-spawn and "additional parameters" to --host /usr/bin/mousepad. Perhaps we should make the DC flatpak add "`flatpak-spawn --host" automatically, so that one can use the same config file for the normal and the flatpak version.

[alexx2000]

This does not work on my end yet. When I try to delete a file with DC in flatpak, I get the error

Where this file is located (home directory, external drive, etc)? In some places trash cannot work.

[TorrSamaho]

My home direction. I tried a file in ~ and one in ~/Documents. This is under Manjaro in case the distro matters.

BTW: I also updated the flatpak to use 5712b87 instead of 1.1.2 and removed my patch for the mount hiding.

[alexx2000]

I added TrashFile() from the org.freedesktop.portal.Trash.

[TorrSamaho]

Thanks! I just tested this with a file in my home directory and it works like a charm. I updated my flatpak version to use dd9704a.

[TorrSamaho]

Another thought: Unsurprisingly, "Open with" doesn't work in the flatpak version yet. One could perhaps redirect this to OpenFile with the option ask=true from the org.freedesktop.portal.OpenURI portal https://docs.flatpak.org/en/latest/portal-api-reference.html#gdbus-method-org-freedesktop-portal-OpenURI.OpenFile

If that works, perhaps xdg-open can be replaced with OpenFile with ask=false to have things more consistent.

[TorrSamaho]

Since 1.1.3 has all the flatpak changes, I updated the flatpak version to use DC 1.1.3.

[TorrSamaho]

I noticed that the flatpak needs more permissions (filesystem=~/.var/app to see/edit the configs of other flatpak apps and filesystem=/tmp since external archivers seem to write there) and added those.

[TorrSamaho]

Thanks for the "open with" flatpak changes, i.e. 0750dc3! Work nicely for me after some quick testing.

[TorrSamaho]

I updated the flatpak to DC 1.1.4 and org.kde.Platform 5.15-23.08.

[TorrSamaho]

Small issue I noticed with the DC flatpak: It does not seem to map Monospace to the system's default monospace font (I noticed this in the built-in viewer), while this works fine in the non-flatpak DC. The DC flatpak sees all fonts installed on the system, so as workaround one can just set the desired font explicitly in DC's config.

[pchmykh]

I updated the flatpak to DC 1.1.4 and org.kde.Platform 5.15-23.08.

Is it possible to install via Flatpak somehow? Thanks!

[alexx2000]

No. I don't recommend to use Flatpak version. It has a limited functionality due flatpak sandbox.

[pchmykh]

No. I don't recommend to use Flatpak version. It has a limited functionality due flatpak sandbox.

Repository version doesn’t start on my fedora 39 :(

[alexx2000]

Open a new issue about it. Execute DC from terminal and copy output there.

[TorrSamaho]

Is it possible to install via Flatpak somehow? Thanks!

If you don't mind building the Flatpak yourself, you can install it. Assuming you have flatpak and flatpak-builder installed, you first need install the necessary SDKs:

flatpak install flathub org.kde.Platform//5.15-23.08 org.kde.Sdk//5.15-23.08 flathub org.freedesktop.Sdk.Extension.freepascal//23.08

Then you should be able to build and install the Flatpak as follows:

git clone https://github.com/TorrSamaho/io.github.doublecmd.DoubleCommander.git
cd io.github.doublecmd.DoubleCommander
flatpak-builder --force-clean build-dir io.github.doublecmd.DoubleCommander.yml
flatpak-builder --user --install --force-clean build-dir io.github.doublecmd.DoubleCommander.yml

After this, the Flatpak version of DC should be installed as any other Flatpak. You can start like any other Flatpak, e.g., from the terminal using

flatpak run io.github.doublecmd.DoubleCommander

No. I don't recommend to use Flatpak version. It has a limited functionality due flatpak sandbox.

Sure, the Flatpak version has limited functionality, but depending on what you use DC for, it may be completely sufficient.

The main reason I started working on this is that there is no DC package for Ubuntu 22.04 ARM64 (at least there was none the last time I checked).

BTW: I updated the flatpak to DC 1.1.9.

[Skif-off]

The main reason I started working on this is that there is no DC package for Ubuntu 22.04 ARM64 (at least there was none the last time I checked).

As I see the Ubuntu repository contains packages for ARMv7 and ARM64 (GTK2/Qt5): maybe it would be more logical to ask to enable the building of packages for these architectures in the openSUSE Build Service?

[skobkin]

maybe it would be more logical to ask to enable the building of packages for these architectures in the openSUSE Build Service

What about SteamDeck users and users of other OSes?

[RokeJulianLockhart]

#309 (comment)

@skobkin, see https://openbuildservice.org/help/manuals/obs-user-guide/cha.obs.package_formats#sec.pkgfmt.flatpak (per https://openbuildservice.org/2021/02/18/introducing-flatpak-builds/). OBS consequently appears to support Flatpak compilation too.

[Skif-off]

@skobkin

I found it on Wiki: "Steam Deck runs SteamOS version 3, based on the Arch Linux operating system". I'm not ready to consider Arch Linux an exotic system.
Also I answered this:

The main reason I started working on this...

@alexx2000

I don't recommend to use Flatpak version. It has a limited functionality due flatpak sandbox.

How can I find out the full list of restrictions? (In the context that we are dealing with a file manager.)

[skobkin]

@Skif-off
You should consider SteamOS because it runs with read-only root FS and you can't use Arch's package manager to install software without breaking system updates. SteamDeck users are heavily relying on Flatpak which is pre-installed in SteamOS.

[RokeJulianLockhart]

#309 (comment)

@Skif-off, https://docs.flatpak.org/en/latest/sandbox-permissions-reference.html#f4 contains and links to a comprehensive list of inode access restrictions. https://docs.flatpak.org/en/latest/sandbox-permissions.html#filesystem-access explains why. Device access should not be problematic, per https://docs.flatpak.org/en/latest/sandbox-permissions.html#device-access.

Arch Linux isn't an exotic system, but SteamOS is in some regards, being a new immutable fork of it.

[Francewhoa]

For those interested to discuss adding DoubleCmd to Flathub repository. You're welcome to join this related new discussion at #1486