flatpak version

[DOCPROF]

Operating system

• Linux

Application

• Desktop

For linux, can you create a flatpak version?

[horizonbrave]

that would be great!

[laurent22]

Need to wait for electron-builder to add support for it

[kurobeats]

it would take an extra step but this could work https://github.com/endlessm/electron-installer-flatpak

[trymeouteh]

Flatpak will be a great option for any Linux user to easily install Joplin.

[Stele77]

IMHO Flatpak support is a much-needed feature and has several benefits:
-The Appimage option always had the problem of integration; Icons in gnome dock never worked and could not be pinned as favorite (at least this was the case with many Appimage Apps including Joplin before i moved to Arch and began to use the AUR package)
-Flatpak seems to be more focused on user apps compared to the more server orientated Snap
-Is supported by GNOME and most big Linux distros as the de facto future app distribution system
-Will be AFAIk used for the renewed push to bring Linux to phones (Librem, Pinephone)
-Bring the security advantages of sandboxing
-Add the wide and distro agnostic reach of the Flathub App Store if that is wanted
Just my 2 cents from a non dev FOSS fan..

[teynav]

Can you please add the support on flatpak, I am a arch linux user and it takes ages to install joplin into my computer from AUR, Linux Mint had previous version, It will be very nice to have joplin on flatpak.

[unsungNovelty]

@teynav - I use Manjaro and the below command works for me as another solution. This will install the .appimage. So it should work just fine on Arch too.

wget -O - https://raw.githubusercontent.com/laurent22/joplin/master/Joplin_install_and_update.sh | bash

Regarding the Flatpak support - This is dependent on electron-builder which is already shared above in the ticket.

~ Another user

[kornava]

How about a snap package for Joplin
I think they have a good support for electron based desktop apps
https://snapcraft.io/docs/electron-apps
AppImage is really painful, even with the provided shell script its always better to have an automated solution for updates

And how about an apt repository for debian users?

[poperigby]

I would recommend against Snaps. Their backend and main repository is proprietary.

[bedwardly-down]

While I wait for my current PR to get reviewed again, I'm messing around with trying to build a flatpak version to solve this issue. So far, what I've found is the flatpak format is barely supported for Electron and is infuriating to setup with only a small handful of node packages available.

This one seems to be the most up to date and stable one available but using it following the page's instructions throws this error in my terminal:

electron-installer-flatpak --src dist/app-linux-x64/ --dest dist/installers/ --arch x64
Creating package (this may take a while)
(node:4922) UnhandledPromiseRejectionWarning: Error: flatpak-builder failed with status code 1
at ChildProcess. (/usr/lib/node_modules/@malept/electron-installer-flatpak/node_modules/@malept/flatpak-bundler/index.js:68:16)
at ChildProcess.emit (events.js:321:20)
at maybeClose (internal/child_process.js:1026:16)
at Process.ChildProcess._handle.onexit (internal/child_process.js:286:5)
(node:4922) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag --unhandled-rejections=strict (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:4922) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Anyone else attempt this yet or have some insight into this?

[bedwardly-down]

I don't have a flatpak created but I do have a debian build if anyone wants to try it out.

[PowerBossNautilus]

Would that help in any way?

[bedwardly-down]

I’d love to see more versions released to help make using Joplin on Linux better but AppImage just works for enough users that I wouldn’t put much credence into this topic ever getting really resolved.

I was recently made a member of the official Joplin team, so I’m trying to get a native implementation going to solve this issue all the way, but it’ll probably be a side project without being a part of the actual project.

[starkers]

I actually just sucesfully made a flatpak (ironically using the latest released AppImage)..

I'll possibly drop this onto a github repo if anyone's interested, also I'm happy to submit+maintain an official one on flatpak.org (this would be my first one so its probably not fully standards compliant yet)

EDIT: I've put this into github - https://github.com/starkers/joplin-flatpak

[starkers]

@laurent22 I've just read the guidelines on getting a flatpak packaged up for everyone on flathub. I do need to do some small modifications but otherwise I should be able to get this published pretty quickly but I would like your permission.

So two paths forward really:

1. would you like that we can release and update flatpaks with your current process? in which case I'll explore your CI sollution and try to PR that, I'm not fully up to spec on the procedures but I am happy to learn and assist
2. I'm happy maintain the official flatpak and build it from the latest AppImage releases. I will of course try to ensure you have ownership of the repo in such a case. (I'll read more and update here if you like)

[laurent22]

@starkers, feel free to go ahead with it, you have my permission. As for the way to release it, how would that work if it's part of CI? Does it mean there will be a flatpaks being built and added to the GitHub release files? or the CI will trigger a build somewhere else and file will appear on Flathub?

[hutson]

Would it be acceptable to ship Joplin with this feature broken? adding an influx of users opening bug reports and complaining about it? - @tinywrkb

Just my two cents, but I would worry about shipping Joplin without external editor support. External editor support is heavily recommended on the Joplin forum for editing embedded images, videos, spreadsheets, etc. Not having it may definitely confuse a large number of users.

[JGCarroll]

You can have a wrapper for xdg-open that wraps calls to the xdg portals, allowing external editor support to work to the extent that the portals are capable for. Which is to say there's still some complaints (E.G, Vim) and UX issues, but it isn't completely broken.

[laurent22]

Leaving it open because there’s enough interest but it won’t be officially supported. However if someone builds one and maintains it we can link to it.

[tinywrkb]

flathub/flathub#2061

[axelsimon]

Just to add that AppImages are fine and dandy, except they don't integrate in any way into a desktop environment such as Gnome, which is used as default by many Linux distributions (oh, like Ubuntu, Debian or Fedora) and they need to be started manually, from a CLI, which is really not nice for regular users. AppImage should be avoided, i would argue, because of this.

[laurent22]

There's now an unofficial flatpak package for those interested.

In general I only want to support one Linux format so if AppImage is not good, I don't mind switching to something else. But the few times this came up there was no good alternative to AppImage.

[fourstepper]

@laurent22 flatpak is THE format I would say distributions that aren't ubuntu use most of the time. The problem is that Ubuntu is majority of the userbase. @axelsimon that's why the install script exists: https://joplinapp.org/#desktop-applications

[paidhi]

Perhaps leveraging the Open Build Service (OBS) would be a viable way. It could create packages & instructions for multiple distributions from a single source. Despite it's history it is not just for OpenSUSE.

Users could download the package from there or add it as a repository and also get future updates. I use it to install & update OpenRazer for Fedora Linux.

OBS can also build Flatpaks and AppImages.

Examples:

• https://software.opensuse.org//download.html?project=home%3Afusionfuture&package=joplin-desktop
• https://software.opensuse.org/download.html?project=hardware%3Arazer&package=openrazer-meta

[paidhi]

Just to add that AppImages are fine and dandy, except they don't integrate in any way into a desktop environment such as Gnome, which is used as default by many Linux distributions (oh, like Ubuntu, Debian or Fedora) and they need to be started manually, from a CLI, which is really not nice for regular users. AppImage should be avoided, i would argue, because of this.

AppImages can be integrated with the desktop environment. But unfortunately it is not straight forward for unexperienced users. One has to know that tools like AppImageLauncher or appimaged exist and how to install them for the specific Linux distribution.

[tinywrkb]

OBS can also build Flatpaks and AppImages.

@paidhi electron-builder recently gained support for building Flatpaks, but like OBS there's only support for Flatpak bundles which I think is not what most users wish for.
Users want to install an app from the Flathub store by using a GUI package manager (e.g. Gnome Software), have the app be updated automatically, and not be forced to manually download and install a new binary release on every update.

I think that using Flatpak bundles as a distribution method is not something that should be encouraged and we need to wait for one of these two desired developments:

• Flathub will gain support to upload bundles. Flatpak developers might need to fix bundles first, like the missing locale bundling support.
• A policy for pushing apps directly to Flathub will be decided on.
  Officially, a Flatpak manifest is the only way to upload and manage apps but Mozilla was allowed to push directly to Flathub.
  This is wrong and feels like playing favorites. If one is being allowed to do this then everyone else should also have this option.
  When this policy would be decided on, proper support should be added to electron-builder.
  There's a related discussion here.

[Perkolator]

Users want to install an app from the Flathub store by using a GUI package manager (e.g. Gnome Software), have the app be updated automatically

Not everyone. If updating is done silently in the background and without authorization, it's a no-go for me. What has happened to the core idea of user in control of the linux box and security? Now pretty much everyone seems to want to have (silent) automatic updates that are applied without sudo.. people don't seem to be interested about what is changing in their programs anymore.

If I had to choose, a PPA would be the absolutely first choice. If I had to choose between AppImage/Flatpak/Snap, I would choose the lesser evil, AppImage.

I wish that Joplin would cater to different needs and not offer just one method of installing the software.

[tinywrkb]

Not everyone. If updating is done silently in the background and without authorization, it's a no-go for me. What has happened to the core idea of user in control of the linux box and security? Now pretty much everyone seems to want to have (silent) automatic updates that are applied without sudo.. people don't seem to be interested about what is changing in their programs anymore.

You can turn off updates, it's not even handled by Flatpak as there's no mechanism or service in Flatpak that updates apps automatically, this is handle by a package manager service or GUI that calls Flatpak.
The user can even mask apps and they will not be updated no matter what.
Even if the user updates an app, there's an option to check out a specific commit/version, so if something is broken, it's pretty easy to downgrade.

[laurent22]

I wish that Joplin would cater to different needs and not offer just one method of installing the software.

It does cater to different needs - there's a Windows build, a macOS one, and a Linux one. The problem is that Linux is quite high maintenance and requires many different builds for many different package managers and distributions. Linux represents 20% of Joplin users but it would take 80% of the time to maintain all these builds.

Basically it's not developers' fault if after all this time Linux desktop is still so fragmented. I wish distros would eventually agree on a common app distribution standard but I don't know if they'll ever get there.

[Perkolator]

I wish distros would eventually agree on a common app distribution standard but I don't know if they'll ever get there.

Same thoughts here. I just recently moved to linux and I had a too rosy image of how the software is distributed and then I learned about AppImage/Flatpak/Snap stuff and became somewhat worried about where things are moving (the idea behind is sound, but the implementations, for now, are not pleasing me). Was really looking forward to ditch windows and how keeping software up to date there took so much time (EDIT: I'm not after automatic updates, what I mean is that finding out and installing new versions of software started to be a burden, Vs. what I thought that in linux world a user has this one update manager that checks and notifies of new versions and keeps everything up-to-date). It seems that fragmentation is a core thing in linux world.. everybody is free to do what they want and there's always lots of people that want different things. A blessing, and a curse (if I may be so bold).

[fourstepper]

@Perkolator I think the situation is not so bad. In my experience, between flatpaks and apt packages you can cover 99% of the users.

On Fedora, people are used to using flatpak. On Arch, someone usually goes and makes an AUR package or they use flatpak. On Ubuntu, people use apt or snap, so apt is probably the better way to go. Debian can use flatpak and Debian users are, I think, getting used to this to get shiny userspace stuff from there nowadays too.

[OdinVex]

I wish that Joplin would cater to different needs and not offer just one method of installing the software.

It does cater to different needs - there's a Windows build, a macOS one, and a Linux one. The problem is that Linux is quite high maintenance and requires many different builds for many different package managers and distributions. Linux represents 20% of Joplin users but it would take 80% of the time to maintain all these builds.

Basically it's not developers' fault if after all this time Linux desktop is still so fragmented. I wish distros would eventually agree on a common app distribution standard but I don't know if they'll ever get there.

Much like using Snap (Ubuntu-only) fragments it even further rather than using a PPA to target all Debian-based or Flatpak for Debian and otherwise... >_> First thing I've always done is removed Snap on any distro using it. My Manjaro rigs can use the AUR, but my Mint rigs need a manual install every time. :/ As I understand it, Snap...and Flatpak...and AppImage...were all created to reduce DLL-Hell. Doesn't solve anything, just fragments further. If I could tolerate M$ I would, I'd rather take DLL-Hell over this kind of fragmentation, but I despise M$.

[Ahmed-E-86]

@laurent22 Is this yours? -> https://flathub.org/apps/details/net.cozic.joplin_desktop

[laurent22]

No, but I'm aware of it and it's well maintained.

[logos88]

Is there any plans for an officially supported version in the future? Flatpak is the new standar and would be interesting to have an official version there

[derkrasseleo]

Would be great if there was official flatpak support, or at least a verified version on flathub.

[ProfessorCode212]

@laurent22 Would it be possible to get the Joplin app on Flathub verified as an official distribution? Flathub has already become quite popular and I believe a lot of people install Joplin that way. Even if you don't maintain the flatpak yourself, it would still provide some legitimacy to it.

CC: @catsout

[mbnoimi]

We still suffer of missing flatpak distro. AppImage isn't a good option at all. It doesn't integrate with the system smoothly.
Some one contributed joplin's flatpak but unfortunately it still in version 2.x :(

I think after 51 comments and lot of thumbs up it's the time to listen to the community and give joplin an official flatpak distro.

[ianchanning]

@mbnoimi The flatpak distribution isn't official but it has been updated to v3 now. A week to wait after a major release isn't that long, and the AppImage worked perfectly in the mean time.

[JGCarroll]

To give some credence to the idea, it's worth looking at some stats.

According to the Joplin website, https://joplinapp.org/help/about/stats/ - The latest available updates suggest something around 25k-40k AppImage users. The issue is, it's impossible to determine duplicate downloads, and the time scale being effectively infinite makes the data difficult to compare since it's unbounded.

On the other hand, the Flatpak appears to have about 15k users, measured by downloads over 2 days. https://klausenbusk.github.io/flathub-stats/#ref=net.cozic.joplin_desktop&downloadType=updates

It does that despite being unofficial.

If the Flatpak were made official, you could easily imagine it overtaking the AppImage in downloads entirely.

Whilst I'm sure some people would demand AppImage anyway, as there'll likely also be people also demanding .deb/.rpm - Does AppImage have any actual benefits to the developers? Alternatively, how much benefit does it have to the users? Flatpak has proved itself reliable for Joplin, and overtime, AppImage increasingly less so.

Whilst I can understanding only wanting one distribution officially, in 2024, is AppImage providing any advantages consider the zero sandboxing, out of date library demands (libfuse2), incomplete library bundles (AppImages make a lot of assumptions on what libraries the system already has), no package signing, inferior desktop integration, etc.

Flatpak becomes both the OS and the installation format. AppImage is every existing OS hiding in sheeps clothing.

IMO it makes sense to offer both, but the preference for both developer and users seems to lean strongly one way vs the other, on average.