AlexMikhalev commented on Jan 18 •

For me this is a major blocker to ship tiny Tauri app, let me know if I can help to debug or progress this bug. I can confirm shortcut trigger works on Mac and doesn't work on Linux (Pop OS 20.04).

nothingismagick commented on Jan 18

Please give us more information. What window compositor are you using? What does tauri info tell you? Have you tried on any other Linux distros?

AlexMikhalev commented on Jan 18 •

tauri info (from next branch)

yarn tauri info         
yarn run v1.22.17
warning package.json: No license field
warning ../../../../package.json: No license field
$ node ../../tooling/cli.js/bin/tauri info
 app:spawn [sync] Running "cargo build --release" +0ms

   Compiling tauri-cli v1.0.0-beta.7 (/home/alex/rust_code/tauri/tooling/cli.rs)
    Finished release [optimized] target(s) in 9.95s
 app:spawn Running "/home/alex/rust_code/tauri/tooling/cli.rs/target/release/cargo-tauri tauri info" +10s


Operating System - Pop!_OS, version 20.04 X64

Node.js environment
  Node.js - 14.17.0
  @tauri-apps/cli - 1.0.0-beta.10
  @tauri-apps/api - 1.0.0-beta.8

Global packages
  npm - 8.3.1
  pnpm - 6.24.4
  yarn - 1.22.17

Rust environment
  rustc - 1.58.0
  cargo - 1.58.0

Rust environment
  rustup - 1.24.3
  rustc - 1.58.0
  cargo - 1.58.0
  toolchain - stable-x86_64-unknown-linux-gnu (default)

App directory structure
/src
/node_modules
/src-tauri
/dist
/public

App
  tauri.rs - 1.0.0-beta.8
  build-type - bundle
  CSP - default-src blob: data: filesystem: ws: wss: http: https: tauri: asset: customprotocol: 'unsafe-eval' 'unsafe-inline' 'self' img-src: 'self'
  distDir - ../dist
  devPath - http://localhost:5000/
  framework - Svelte

Pop!_OS 20.04 LTS (with Nvidia drivers)
gdm, GNOME 3.36.8, Xwindows/X11
What other information would be helpful?
I don't have any other linux setup.

AlexMikhalev commented on Jan 18 •

Strangely Ctrl-T/CTRL+D for test/disable submenu works. Global shortcut only registered but never triggers.

nothingismagick commented on Jan 18

ok, we need to try to replicate this. thanks for the insight!

AlexMikhalev commented on Jan 19

@nothingismagick let me know if I can help debug it further - I don't mind running tauri under gdb or anything which will produce useful logs for you.

nothingismagick commented on Jan 19

cheers. am going to ask @wusyong to have a look and see if he can replicate.

AlexMikhalev commented on Jan 24

I have tried it on a clean install of pop os 20.04 and on 21.04, the issue is persistent.

wusyong commented on Jan 25

I also plan to revision our global handler since it's still only available on x11.
We should use Gtk's accelerator group already.

AlexMikhalev commented on Feb 10

Hurrah! I am going to test tonight.

AlexMikhalev commented on Feb 10

I think that broke now register in JS, if I run example/api and try to register global shortcut I get an empty array in Tauri console (screenshot) and error in JS console:

[Error] Unhandled Promise Rejection: TypeError: undefined is not an object (evaluating 'window.rpc.notify')
	promiseEmptyOnRejected (chunk-KSXZ7OFV.js:136)
	promiseReactionJob

api git:(next) ✗ cargo tree | grep tao
│       ├── tao v0.6.1
➜  api git:(next) ✗ 

FabianLars commented on Feb 10

@AlexMikhalev i think you need to re-build the api package (cd tooling/api && yarn && yarn build). This is unrelated to this tao change tho, and caused by the huge audit changes.

AlexMikhalev commented on Feb 10

I rebuild before reporting the bug. I also rebuild it following the advice above, but global shortcuts are not triggered or registering now.
Promise rejection is at the start of the Tauri app, that's not related to the bug above.

amrbashir commented on Feb 10

@AlexMikhalev the promise rejection error is as stated by Fabian because of outdated api package. Please wait for the new release which should be so soon or test the globalShortcut functionality using tao directly, you can find an example in the examples directory in tao repo.

AlexMikhalev commented on Feb 11

@amrbashir ok, waiting for the new release of Tauri with bugfix. This probably means the bug isn't closed yet.

FabianLars commented on Feb 11

@AlexMikhalev We released the first rc version yesterday

wusyong commented 6 days ago

We are looking for help! I couldn't reproduce this in my PC, laptop and even VM. But there are still people have this issue.
On x11, we listen XNextEvent here. And according to people that has trouble, XPending is always 0 for some reason despite they already typed several different keys.
And on wayland, we simply haven't done it yet. Contribution is welcome!

jplatte commented 6 days ago

What does "global" shortcut mean? Wayland intentionally doesn't let you read keyboard events when your window is not focused.

wusyong commented 6 days ago

Yeah, you are right. I forgot to mention #331 too. wayland-protocols has an RFC about this but doesn't seem pretty active recently.

FabianLars commented 6 days ago •

For whatever reason github didn't save my message so i try my best to replicate it from memory

Wayland intentionally doesn't let you read keyboard events

Yep we know that, but:

• global shortcut don't work for some users on x11 either (this is what this issue was about)
• the current implementation doesn't work for focused wayland windows either
• if i remember correctly, we found a workaround to make global shortcuts work in a wayland session via winit's DeviceEvent::Key

amrbashir commented 6 days ago

if i remember correctly, we found a workaround to make global shortcuts work in a wayland session via winit's DeviceEvent::Key

That is not right, DeviceEvent::Key is not supported on wayland.

This issue should just focus on x11 and wait for wayland to implement a protocol for global device events.

FabianLars commented 6 days ago •

Yeah you're right, just checked our convo again and I wasn't even able to spawn a winit window on Wayland back then (it still doesn't work and it's still crashing my system )

but the device events were working correctly on (x11) systems where our current shortcut implementation doesn't work, so that's what I mixed up in my previous comment.