electron VS flatpak-external-data-checker

Still trash support on Linux too. We still cannot stream without frame rate issues and cannot stream audio with our video without piping through our mics. (the community fixed this for you: link)

SteamDeck and Linux users cannot stream properly (constant frame rate issues and absolutely no audio streaming). Its been FIXED by the community for years now (https://github.com/discord/electron/pull/22) but they just don't want to do it I guess?? If you are going to support the platform, SUPPORT THE PLATFORM. I'm not going to give you money for a product that doesn't work.

There is this https://github.com/discord/electron/tree/17-x-y from over half a year ago

But my golly gosh goodness me would I throw them a party in their honor if they would just update their 2 year out of date builtin shipped electron version that prevents all the progress we've made in the past few years from being at all relevant to their client.

You can see Discord's version of Electron on GitHub: This branch is 14 commits ahead, 2140 commits behind electron:main

The article from your quick google share says that you should use getUserMedia to capture the screen using Electron. Not only does Discord's client not use this, they even go as far as to disable it from their electron fork https://github.com/discord/electron/commit/e763956140aa6bf78f02202ab4df1e942ce672ae

They even forcefully disabled support for it in their version of electron, so there isn't even a way to use it via a betterdiscord plugin

The Discord Desktop app uses Electron and their Electron fork's source code is available on Github. If you take a look at their repo you'll see that one of the patches they apply is this one https://github.com/discord/electron/commit/ca8c921ed35c741acae57ea32c340f1eaf150044 that disables getUserMedia.

> Maybe. The CI rules should be made public in that case, though, surely? Maybe they are?

Agreed, but thankfully they are. The PRs link to <https://github.com/flathub/flatpak-external-data-checker>. That said, it'd be clearer if the flathubbot 'user' profile also linked to that URL.

> The enormous amount of value the distros bring [...] is audit of packages (and packaging).

Yes, auditing against supply chain attacks is good! But there's also a risk in running outdated software. I don't have easy answers. But if automation leaves more time for the hard part, great.

Flathub provides an excellent tool to keep your dependencies up to date, so it's just a matter of adding it to the manifests. Besides, who says 'dependencies not being updated enough' is a valid metric to determine the quality of a package? LOL.

According to Github issue/PR #126 new builds are failing because of a bug in flatpak-external-data-checker or some incompatibility between the two projects at least.

I'm surprised the documentation says that since Flathub itself runs its CLI scripts via Flatpak: https://github.com/flathub/flatpak-external-data-checker

Another thing you could add would be to tag your releases on GitHub, add a tag field next to the commit one, and add an x-checker-data section to the manifest so the Flathub bot will automatically open PRs to update the Flatpak release when you update your repository.

See f-e-d-c, and if you're not planing to submit to Flathub, then look at the GitHub workflow example there. Be aware that auto-merging is not acceptable for anything other than extra-data sources.

Unfortunately the maintainership of the Zoom Flatpak on Flathub has been a bit slow, but you can still install it since the Flathub bot do automatic builds whenever there's an update, thanks to the provided flatpak-external-data-checker service.

There is https://github.com/flathub/flatpak-external-data-checker which automatizes the update pull requests including dependencies. Flatpak has other downsides, but security or not getting the latest and greatest is not one of them.