I really love Vencord, it's so nice to use including the better screen sharing support on Linux. But this is the only feature I really wish it had. I wonder if it can be done with a plugin?

I'm thinking of leveraging the new PluginNative functionality that was committed to Vencord a few days ago.
It'd expose any keybindable Discord action (but mainly PTT, initially) to the kglobalaccel DBus, allowing users to setup keybinds via KDE systemsettings.

We already talked about this in the Discord and I think it would probably be better to just implement this in Vesktop using Electron global shortcuts API as this is already cross-platform
This also makes it easier to implement a UI directly inside Discord for it

The only disadvantage is that it wouldn't work for the browser extension this way

yes, this should definitely be part of vesktop and not a plugin

either via electron's global shortcut api, or via iohook

the former does not support things like mouse side buttons and has no way to implement PTT, the latter would require a native module

yes, this should definitely be part of vesktop and not a plugin

either via electron's global shortcut api, or via iohook

the former does not support things like mouse side buttons and has no way to implement PTT, the latter would require a native module

Correct me if I'm wrong but as the latter uses libuiohook I think that it will not support wayland.

I think the electron shortcut API is the right way to go as it is probably the most portable and clean

Edit: Just checked and libuiohook does not support wayland

I am working on this. iohook is old and unmaintained. I am using uiohook-naapi to do this. it also uses libuiohook, and it seems wayland support is in the works. Nothing you can do but wait until libuiohook updates for that, but i'll go ahead and keep using it.

I am working on this. iohook is old and unmaintained. I am using uiohook-naapi to do this. it also uses libuiohook, and it seems wayland support is in the works. Nothing you can do but wait until libuiohook updates for that, but i'll go ahead and keep using it.

Why not use the xdg-desktop-shortcuts? It's way more clean & portable imo (no low level hooking and such)

Didn't know about those, I'll look into it

Although the question here is, is it beneficial to do this, when we'd need a separate, likely more low-level implementation for windows/mac? from my understanding libuiohook works on all platforms

Although the question here is, is it beneficial to do this, when we'd need a separate, likely more low-level implementation for windows/mac? from my understanding libuiohook works on all platforms

For windows one could use RegisterHotKey, which allows for less combinations of keys but also comes with less drawbacks, not sure on MacOS though, I'd suspect they also have some sort of system API for hotkeys instead of allowing for low level hooks

Edit: This is a rather difficult topic as all platforms do it differently, I don't think there's any library out there supporting xdg-desktop-shortcuts, Windows' RegisterHotKey and MacOS - I may write one myself soon as I'd need something like this for Soundux anyways

libuiohook may not be using these exact things, but it already supports all these platforms.. why reinvent the wheel? It also seemingly has less limitations than RegisterHotKey

libuiohook may not be using these exact things, but it already supports all these platforms.. why reinvent the wheel? It also seemingly has less limitations than RegisterHotKey

Low Level Keyboard Hooks are not exactly a good practice imo.

We've been using them in soundux and have faced several issues:

• Due to their nature, they will not work on Wayland at all

• Low-Level keyboard hooks require custom logic that is not always the same as that implemented by the system and may confuse users due to subtle differences

• Especially on Windows, we've encountered several issues:

  • Depending on the implementation, all system input may lag when the application that has the keys hooked lags
  • some anti cheats seem to have issues with this approach and will out right block the hook thus preventing hotkeys from working

If one wants to better integrate with the target system, xdg-desktop-shortcuts is the way to go on Linux imho, as for the other platforms it's up to the developer on which approach he wants to take, but as listed above there are also several disadvantages to low Level Keyboard Hooks on Windows

I agree that Linux Vesktop should be using xdg-desktop-portal GlobalShortcuts.
Compared to my previous suggestion, it has the benefit of being Desktop Environment-agnostic. It would also make it compatible with Flakpak, for the folks who use that. The DBus interface is at org.freedesktop.portal.GlobalShortcuts.

It would be nice to have it implemented in Electron as a part of the existing global shortcuts API, then Vesktop could use it and be OS agnostic.
electron/electron#38288

xdg-desktop-portal's globalshortcuts api isn't implemented in most implementations. i don't think it's viable to use.
perhaps we could use libuiohook and for wayland users we could have a way of hooking up a shortcut in their wm to a specific action?

xdg-desktop-portal's globalshortcuts api isn't implemented in most implementations. i don't think it's viable to use.

I think it would be good practice to adopt this already even though some WMs don't have it implemented already (KDE has already) because it will probably become the standard soon (especially since it's designed to become a standard)

perhaps we could use libuiohook and for wayland users we could have a way of hooking up a shortcut in their wm to a specific action?

This is also not too bad, one could use some sort of cli to trigger certain actions in vesktop - However I don't think it would really be worth the effort especially since we'd probably want to switch to x-d-p implementation once it's more wide spread

Perhaps I could implement a native module similar to libuiohook which supports x-d-p global shortcuts as well as a X11 Keyboard Hook and Windows either through a LL-Keyboard Hook (and maybe even RegisterHotkey).

I'd need a library like that for personal projects anyways, in case this would be of consideration for Vesktop, are there any preferences on how the API should look like?

For me personally this would be a great improvement, right now on Wayland I have to choose between having no Push-To-Talk using vencord in browser or via the client, but having working screen capture. Or the default client with no working screen capture and less important no plugins.

As far as I know there is no software solution that allows both push-to-talk and screen capture on Wayland.
In practice for me this means falling back to the default client to talk in voice, be it without good screen capture.

Could there be an API-based solution for this? Specifically expose some sort of API and allow platform specific applications like AHK to plug into these APIs?

if you check out #326 the most recent commit kinda does that. it exposes a cli that can execute different keybinds by code. though i was thinking this would be used as fallback.
plans are being made for better ways to do this but i am really busy with school as of right now and can't really contribute much.

if you check out #326 the most recent commit kinda does that. it exposes a cli that can execute different keybinds by code. though i was thinking this would be used as fallback. plans are being made for better ways to do this but i am really busy with school as of right now and can't really contribute much.

This looks like a great first step! Does this only work for oneshot keybinds or would this work with push to talk too potentially in the future?

the older(and now removed) electron api based global shortcut handler didn't at all support push to talk
the current cli doesn't handle pressed and unpressed states tho it should be super easy to add
we are planning better ways to do this. i was thinking the cli could be used as fallback for wayland users. currently the only way to handle keybinds for wayland users is through xdg-desktop-portals which last time i checked didn't really have a mature implentation of this. though it probably has gotten better.

Strongly in favor of a socket or CLI interface for controlling the push-to-talk up/down events. It could be invaluable as both a stopgap solution and as a fallback, even if it is more of a DIY approach.

This workaround runs as a privileged process (or with the desired device made user-readable) and listens for evdev events on a given device/button, and then forwards a given Xorg key event to XWayland, via libxdo (using the XTEST extension protocol). This is the relatively brittle hack that I currently use to have global PTT support the official client.

it works on Arch for now, but is completely broken on Fedora with GNOME. Fedora (and maybe more distros, in the future) build their gnome-shell/mutter with support for an input emulation library, which consumes the events from XTEST. Every time a GNOME user on Fedora attempts to send simulated events to XWayland, an XDG portal "remote access" dialog pops up. Even when you choose to allow access from this dialog, the events never actually get sent to XWayland and its clients.

If Vesktop had an interface to control the PTT microphone state, I could simply take the existing evdev listener program and bolt it onto that, in place of libxdo. This workaround would not be exclusive to Wayland nor Xorg, and would not require waiting for the XDG Global Shortcuts implementations to land in each DE (and in Electron.)

just use global shortcuts portal and x11 can cope

allowing external control seems smart tho as a separate option

just use global shortcuts portal and x11 can cope

allowing external control seems smart tho as a separate option

The thing about the XDG global shortcut protocol, if I'm not mistaken, is that it will still take a while longer for the implementations to appear. Especially outside of rolling distros that follow upstream closely. Even though the protocol/spec itself is complete, and Plasma is said to support it, GNOME and wlroots are still in the design phases of their implementations. (This is absolutely not intended as criticism or impatience; I know these are all volunteer-driven projects, wanting to design things as correctly and maintainably as possible.)

Electron still has its own issue open (linked further up this thread), discussing how best to support the XDG global shortcuts protocol, or whether it can be done transparently in a way that replaces the old global shortcut system. With the external control interface as a stopgap, even once those pieces did fall into place, Vesktop could have a relatively stable option that is entirely compositor/desktop-agnostic, but also separate enough (like you said) that any future changes in Electron would likely not conflict with it.

I do not disagree on anything per se, but only wanted to articulate how/why I believe the external control or CLI would be equally helpful to Xorg and Wayland users in the meantime, regardless of their distro or package versions, and not require waiting for other projects to catch up.

Might not belong here, but in addition to adding custom keybinds could there also be a feature to disable discord's default keybinds? Ex. disabling CTRL+' to start a group call.

Might not belong here, but in addition to adding custom keybinds could there also be a feature to disable discord's default keybinds? Ex. disabling CTRL+' to start a group call.

with the regular discord client you could create keybinds and leave them unassigned to do this

will this be implemented? i really hope it will

#326 used to use the electron globalshortcuts api (i believe that's the one you are using right now) which doesn't work on wayland (by default without hacky solutions), can't do PTT, and consumes inputs.

i've since changed it to have a cli which you can hook up any DE's keybind system to. currently it doesn't support PTT either but that should be fairly easy to add.

though my intention with the cli is for it to be used more as a fallback than the main solution. and there isn't anything else besides the cli in #326 so i don't think it's entirely ready for general use either

Oh, I didn't notice you changed the way the PR works. I'm still using the old method in my branch which as outlined before works perfectly fine for my usecase. I've just thrown that in here because it might be of interest to others too.

Author of the before-mentioned https://github.com/Rush/wayland-push-to-talk-fix here - which Vesktop branch should I be using? :-) I need to have a working screen sharing solution on Linux.

@D3SOX I built your version. I like your tray icon feature. How would I use global shortcuts? I am starting via ./dist/linux-unpacked/vesktop.

Unfortunately I am not on Arch so can't leverage your PKGBUILD. openSUSE here.

@Rush Screen sharing is already upstreamed for a while now so as long as that branch is up-to-date you're fine.

For global shortcuts be warned that push to talk does not work and you need to be on X11 or KDE on Wayland and enable Legacy X11 App Support in settings. Then just use Discord's keybind settings.

As for packaging, just refer to the README and feel free to use whatever you like that Electron Builder supports (I think RPM and AppImage is supported)

For global shortcuts be warned that push to talk does not work and you need to be on X11 or KDE on Wayland and enable Legacy X11 App Support in settings. Then just use Discord's keybind settings.

Cool. I was able to have Mute work via a global keybind - but I am seeing an issue when Discord is out of focus. When in focus it's instant, when out of focus it sometimes takes half a second for mute to take effects. Did you see that?

@Rush No it works for me when it's not focused. Which Discord client and desktop environment are you using?

@Rush No it works for me when it's not focused. Which Discord client and desktop environment are you using?

It works, it's just delayed & laggy when Vesktop is not focused. Using your Vesktop fork. KDE. I opted for the "Legacy X11 App Support" way and its keystrokes redirection.

@Rush Can you try running Vesktop with --disable-renderer-backgrounding and see if that resolves the lag issue?

Can't we do bindings like discord screenaudio?

Can't we do bindings like discord screenaudio?

I will take a look at #609

my pr has a cli for this purpose. i have also added support for keyup/down states in my most recent commit.

Can't we do bindings like discord screenaudio?

That's dependent on KGlobalAccel, correct?

That's dependent on KGlobalAccel, correct?

Looks like it is. I'm not sure that we can use it directly it TS code, so for implementing this behavior we can write some C++ helper code (?). But here is the question of why if we can use just default custom keybinds and do not complicate the project structure.
discord-screenaudio is already on C++ so using KGlobalAccel is way easier for them.

That's dependent on KGlobalAccel, correct?

Looks like it is. I'm not sure that we can use it directly it TS code, so for implementing this behavior we can write some C++ helper code (?). But here is the question of why if we can use just default custom keybinds and do not complicate the project structure.
discord-screenaudio is already on C++ so using KGlobalAccel is way easier for them.

#18 (comment)

I am not sure if KGlobalAccel supports sending separate key up/down events, either, which are pretty much a requirement for PTT. I would absolutely second the XDG Global Shortcuts module idea, depending on how difficult you think it'd be. Unless bolting on C++ is unacceptably messy and a blocker in its own right. Or unless there's a TS API I'm not aware of, for udev or XDG shortcuts. I have not seen any relevant activity, lately, in upstream Electron.

I can confirm Plasma's global shortcut portal works great. It's exposed in the same System Settings menu seen in the recent screenshot. I've played with it using this example C++/Qt application. Hyprland claims support, too, but I have personally never tried that compositor. GNOME has a contributor actively working on implementing it in the same manner as Plasma (inside their existing keyboard settings.)

Unless bolting on C++ is unacceptably messy and a blocker in its own right

Not sure what you mean here, venmic is already written entirely in C++

Unless bolting on C++ is unacceptably messy and a blocker in its own right

Not sure what you mean here, venmic is already written entirely in C++

That does answer my question (whether the developers are okay with features that would require C++ helpers.) Sorry if it was poorly phrased. I had not seen that there was a separate repo for Pipewire screenshare, so at a glance, it looked like the project could've been aiming for as much pure TypeScript as possible.

Just quickly adding that GNOME should support the XDG Global Shortcuts soon enough (hopefully). Here's the open merge request if anyone wants to keep up with it.

Hey @tuxinal , can I help w something?
I'm very interested in the keybinds, and I also would like to add some things that the discord official client doesn't have (such as toggle noise supression)

are there any workarounds at the moment to enable global push to talk in vesktop?

are there any workarounds at the moment to enable global push to talk in vesktop?

Does building with #326 or #609 work for your use case?

are there any workarounds at the moment to enable global push to talk in vesktop?

Does building with #326 or #609 work for your use case?

Alternate/standalone workarounds

If not, there are a few projects on GitHub to do this globally, by using the Pipewire API to toggle the entire mic. Push2talk is quite polished, but does not currently support binding mouse buttons. I ended up kludging a C++ equivalent for my personal use case involving mouse buttons and foot pedals. I have been using it for 3 months without problems.

Note that since these evdev+Pipewire approaches don't rely on xdo or portals, they'll work across all X WMs and Wayland compositors. However, the user running the program must belong to the `input` group or be root, so this is not as secure as the XDG portal approach.

I'm embarrassed to admit that my skills aren't that great, but here's my analysis of those PRs:

1. feat: Add global shortcuts #326 says "i'm using electron's globalShortcuts api here which doesn't have a way to detect tell the difference between keyup and keydown. this means the push to talk/mute/deafen/etc actions don't really work" - therefore I don't think it would work for push to talk!
2. I feel like a dumbass but I have no idea how I would use feat: Toggle voice status using fifo pipe #609 and setup push to talk in Hyprland. Maybe someone smarter than me can tell me what I could do

@rbutera Since you mention Hyprland: they have support for the pass dispatcher, which you can use. See also hyprwm/Hyprland#2072

@rbutera i'm no longer using electron's api

@rbutera Since you mention Hyprland: they have support for the pass dispatcher, which you can use. See also hyprwm/Hyprland#2072

Thanks @cpiber i was able to get discords official push to talk working using the pass dispatcher.

For some reason Vesktop doesnt respond to push to talk even if I'm using that dispatcher. I can bind the key in voice/video but even if Vesktop is focused I can't get my mic to activate.

@tuxinal do you think your work will be relevant to this situation?

I'd really like to use vesktop as my main discord client and this is the last obstacle for me

for hyprland specifically we should be able to support it through x-d-p globalshortcuts when it's implemented in venbind: https://wiki.hyprland.org/Configuring/Binds/#dbus-global-shortcuts

but for now you can use my PR and hook up your own keybinds to the current cli