Arch Linux User Repository

As of 2024-09-16, this package is being co-maintained by official vesktop developers, and any packaging decisions they make will not be questioned on my part unless it's something harmful for the users, which is very unlikely to happen. As I see it coming, they will not use the system's electron on this package purposely, if you don't like it, use vesktop-electron, which is also maintained by the same devs.

Thanks!

@alphabitserial That desktop file launching the binary itself is a con here, not a pro because the binary with the embedded electron is not being used in this package. It only installs the app.asar and launches it using the system electron. That's all the shell "binary" is doing.

And I'd like to keep my desktop file synced with upstream, but right now looking here it doesn't seem to have a StartupWMClass anymore.

I've fixed the hash, but why you do want me to add you as a co-maintainer?

package has moved to https://aur.archlinux.org/packages/vesktop

Hi - please update the .desktop file SHA sums. Also, do you mind adding me as co-maintainer? Thanks!

The upstream packaging solution generates its own desktop file - it would be preferable to use it instead of the one this package is currently using.

1. It launches the 'vesktop' binary directly instead of using a shell script
2. It properly sets the StartupWMClass, which fixes an issue wherein open Vesktop windows are not properly associated with pinned application launchers (see: https://github.com/Vencord/Vesktop/issues/305)

Alternatively, you could update the desktop file here; but then you need to keep it in sync with upstream changes.

@solonovamax Using which electron doesn't work because, afaik, it only works with exact matches. I did add -maxdepth 1 to fix the problem you mentioned.

The funny sed and find magic that you have in the buildscript causes the build to fail if slack-desktop is installed.

This is because slack-desktop creates a folder, /usr/lib/slack/resources/app.asar.unpacked/node_modules/electron-native-auth, however this folder does not actually contain electron. It only contains a bin and build directory. And, because of the ordering of directories due to find, this directory occurs last. It is just by happenstance that /usr/lib/electron22 and /usr/lib/electron25 come after other valid matches, such as /usr/lib/node_modules/@bitwarden/cli/node_modules/electron-to-chromium, /usr/lib/code/out/vs/code/electron-main, /usr/lib/code/out/vs/code/electron-sandbox, /usr/lib/code/out/vs/base/parts/sandbox/electron-sandbox, /usr/lib/code/out/vs/platform/profiling/electron-sandbox, and /usr/lib/geogebra/resources/app/node_modules/electron-store.

I looked at how you're matching a valid version of electron, and that's probably not a good way. Might be better to do smth like which electron and grab that path instead.

Package now looks for any electron installation in /usr/lib/.

The build fails with those electron packages because there is no /usr/lib/electron if they are your only electron package. I'll try to see if I can sed the correct /usr/lib/electron* path to electron-builder in the PKGBUILD.

And for the second issue, it looks like it's just using the path of its executable (in this case electron) for the .desktop file, but without any parameters. This might be something that can be fixed on vencord's/vesktop's side.

There is also an issue where enabling autostart will generate a shortcut in .config/autostart that instead of starting /usr/bin/vencord-desktop starts /usr/lib/electron25/electron so the user needs to either manually fix it or create their own startup shortcut.