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!

@Edu4rdSHL Sure, I can even just give you maintainership of this package. I only created it because the -git package did not use system electron.

@picokan, just to help you maintain it and improve some things, nothing in special. I already maintain several packages, I would like to help with this one which I use day to day.

@picokan It looks like the latest update you've pushed has fixed the StartupWMClass issue, thanks! Good to know about the reason for the shell script.

@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.