Insync as Flatpak (Linux)

Yes. Looking foward to move to Fedora Silverblue and Flatpak support would be way to go. I suggests the devs to look into Flatpak 1.6 capabilities and if it really doesn’t work contact the Flatpak developers and see what can be done as the future of linux applications is in containerization.

1 Like

I’m also interested in a Flatpak.
I see you use a Unix file socket for communication of file manager extensions with Insync. Considering Flatpak doesn’t isolate and manages network namespaces you could just switch to a Linux named socket.

1 Like

Here’s a POC Flatpak.

Issues:

  1. As expected the creation of the Unix file socket in /tmp means Flatpak needs to mount /tmp from the host.
    A Linux named socket would be a better solution as it could be shared across containers as long as they use the same network namespace.

  2. It seems like ~/.config is hardcoded and Insync does not respect XDG_CONFIG_HOME.

  3. At least on my testing system, the tray bar status icon is missing. My current guess is that /usr/share/icons/hicolor/48x48/status is hardcoded. Insync should respect XDG_DATA_DIRS or at least use a relative path to share/icons/hicolor/48x48/status from lib/insync/insync exectuable.

4 Likes

I’ve been an Insync user for sometime. I’d really like to echo a strong desire to see flatpak support. Is there any way to prioritize this? It would be such a help to those who have problems getting Insync onto Linux distros that are not officially supported. Thank you developers for considering!

Hey Insync people, this is from 2017???

You still need a reason to put stuff on flatpak and snapcraft? You really think people like to add your apt/rpm repo to their systems?

And you need another reason? Here’s one, fresh install and I can’t use insync

Hi @renatomefidf,

To my understanding you’re on Fedora 35 right now, correct? If so, could you let me know if this workaround works for you?

Hey @mia, a great catch, it did help with it!
Do you know how we could avoid this sort of environment issues completely? Flatpak and Snap! If the Product team still needed some more evidence, here it is.

Thanks for helping me, you were spot on!

2 Likes

Glad to know the workaround was helpful, @renatomefidf! :slight_smile:

I’ll bring this up with our Product team as well as our Linux team to address the env issues that you guys have been experiencing! Many, many thanks for your patience and continued trust in us!

1 Like

Do you guys have any release date for the flatpak version?

Hi @sitompul, no ETA yet; this is not yet part of our feature releases nor our pipeline since we are currently focusing on sync issues and performance improvements.

It’s a real shame that you’re ignoring Flatpak completely, I’m already running Insync as a Flatpak app, and there are not a lot of issues that are needed to be addressed.

  1. Fix the empty status bar icon issue by changing the icon names, so they could be exported by Flatpak. For example, if we give the app a Flatpak app-id of com.insynchq.Insync then the insync-alert icon should be renamed to com.insynchq.Insync-alert or com.insynchq.Insync.alert or com.insynchq.Insync.status-alert.
    This only happen when using SNI protocol, not with XEMBED, but the latter should die with X.
    A possible workaround, is to have the user copy the status bar icons to the host, and manually update the icon theme cache. Last time I tried, it worked, but it should be avoided if possible, and the fix is pretty simple.

  2. Switch or allow choosing the IPC type when starting the app, and support this IPC channel in file-manager extensions.
    This is needed to avoid giving access to the host’s /tmp folder, a filesystem permission that might not be enabled by maintainers of file-manager Flatpak apps.
    This is not a blocking issue but would be great to have.
    Using an abstact Linux socket instead of the Unix file socket will not require much added code. D-Bus would be nicer, but that will require much more work.
    This is not a major issue, we could allow access to /tmp, but it’s better to fix this.

  3. Disable the native file dialog when selecting the local folder where Insync will sync to/from when setting up a cloud service. This will help avoid the Flatpak File portal.
    Without this, the user won’t be able to change the synced folder location, as the File portal was initially designed to give a file descriptor of host’s files, not a folder path.
    I’m not sure if this issue exists in an updated Qt5 release, but it’s definitely a problem in the outdated Qt5 version that is distributed with Insync.
    The workaround, manually editing ~/.config/Insync/data/gd-*.db is not acceptable.

  4. Properly split XDG_CURRENT_DESKTOP value on colons.
    At least in my environment, Sway+Waybar, to have Insync use SNI for the system status bar, I have to change the value of XDG_CURRENT_DESKTOP to Unity from sway:GNOME:Unity: as Insync does not correctly split on colons.
    I’m not sure if this is Insync fault or Qt5. If it’s the latter, then I guess we could document this issue and its workaround.

  5. Actually test the Flatpak app before an update. I stopped keeping track of how many times Wayland was broken, or the app used software rendering because it failed setting up an EGL context.
    Now I just make sure that the app will always have X11 socket access to have it start even if its Wayland support is broken.

  6. Support the background portal.
    I actually don’t care about this as I don’t use a desktop environment, but users who do will appreciate this feature.
    This is optional, but would be nice to have.

3 Likes

@tinywrkb Thank you for such a detailed walk-through on your experience running Insync as a Flatpak app. I have forwarded this to our Product team as it depicts how important this feature is for our Linux community.

2 Likes

Hi everybody!

I’m on Fedora Silverblue and want Flatpak.
Have Progress on task?

1 Like

A few weeks ago I made this request. I hope the team does. It will solve many dependency and incompatibility issues. Looking forward to this feature.

1 Like

update: it is being considered for either this upcoming coding cycle or the next. each coding cycle lasts about 2 months.

5 Likes

Do you have any updates on progress with a Flatpak version? I switched to Fedora Silverblue and I can’t install insync using the rpm.

Flatpaks are the future for applications moving forward because they are secure (sandboxed) and portable (works on most/all distros). And they are completely open-source unlike Canonical’s snap.

Thank you!

1 Like

Hey @Jason_Lee! I’ll circle back on this to check where it is in the roadmap. We’ve had to make some major adjustments in the last few cycles to prioritize squashing bugs :bug:

Thank you for bumping this thread!

1 Like

+1 on Flatpak. I am a long time user and am looking to migrate to Clear Linux, definitely need this.

2 Likes

Definitely looking forward to Flatpak support. Flatpak support would get Insync on a lot of distros besides just Debian and Fedora.

4 Likes

Until there is a Flatpak available Silverblue users can add Insync by adding the Insync repo and installing via rpm-ostree. That’s what I’ve done. However, I’d much, much prefer a Flatpak.

2 Likes