[META] Wayland: text insertion, hotkeys, and Flathub publication

[koloved]

🎯 Goal

Consolidate all open issues and PRs related to Wayland and text insertion via hotkeys into a single tracker. Simplify the maintainer's (@cjpais) process for merging solutions and tracking problems caused by major differences between Linux distributions.

Core problem: Wayland has no single API for programmatic text insertion or registering global hotkeys. Each compositor (GNOME/Mutter, KDE/KWin, wlroots-based compositors) implements different protocols. This leads to fragmented solutions and duplicated effort.

---

📦 Flatpak — the universal distribution method for all distributions

Rationale

Problem	Solution via Flatpak
Atomic systems (Bazzite, Fedora Atomic, SteamOS) — cannot install ydotool/wtype/dotool via package manager	Flatpak includes all dependencies inside the sandbox
Different library versions across distributions (Ubuntu 22.04 vs Arch vs Fedora 43)	Flatpak uses a single runtime (GNOME Platform)
GlobalShortcuts portal requires a correct app_id	Flatpak guarantees a stable com.pais.handy
Different package managers (apt, dnf, pacman, rpm-ostree)	One format for all
Auto-updates	Flathub + x-checker-data automatically updates versions

Current status

• PR feat: add Flatpak packaging support #548 (@GabeDuarteM) — Flatpak packaging support added (open, awaiting merge)
• PR Feat/add remote desktop direct mode on wayland #689 (@petit-aigle, @D3nis) — Remote Desktop portal for Wayland (required for Flatpak)
• PR feat(linux): add xdg-desktop-portal GlobalShortcuts backend for Wayland #1287 (@nmcbride) — GlobalShortcuts portal backend (required for hotkeys in Flatpak)
  - PR fix(linux): wayland paste reliability + post-process transcript loss #1395 (@vetmiker) — Wayland paste & post-process fix (seems not works and not needed in Flatpak)
• testing Flatpak builds on Bazzite (KDE Wayland), finding issues (set_resizable workaround for title bar buttons, pure Wayland support)

---

📋 Open ISSUES (require resolution)

Wayland + text insertion

Issue	Description	Environment
#1549	GNOME Wayland: keycombo paste picks wtype then fails with no fallback; ExternalScript paste hangs via wl-copy	GNOME Wayland
#1282	Post-processing never triggers on Linux KDE Wayland (v0.8.2)	KDE Wayland
#429	First character missing when using Direct paste method on GNOME/Wayland	GNOME Wayland
#1375	Wayland: recording overlay displayed on secondary monitor	Kubuntu/GNOME Wayland
#439	Paste Method > Direct does not use the correct keyboard layout	Wayland
#315	Typing fails due to target window not focused at correct time	Wayland
#1019	Linux version does not allow transcribe shortcut to be a single key	Linux

Wayland + hotkeys

Issue	Description	Environment
#102	Keyboard Shortcut not working on Ubuntu 22.04	Ubuntu/X11
#949	Global shortcuts don't work on Wayland compositors (COSMIC, Sway, Hyprland)	Wayland
#1236	GlobalShortcuts portal broken on GNOME 49	GNOME Wayland

Linux (general)

Issue	Description
#806	No microphone on Pop!_OS 24.04 (PipeWire)
#521	Microphone and Output Device only detected as "Default" on Linux
#1162	Push-to-talk sometimes gets stuck in Cancel state
#1313	GPU not detected (Linux)
#227	Handy crashes on Ubuntu 22.04
#1339	Microphone not detected on Linux
#703	Noticeable delay before Ready beep
#1105	F13-F24 hotkeys fail with "Unknown scancode" (X11)
#373	Title bar buttons do not react until window maximization toggled
#512	AppImage: pkill -USR2 crashes handy
#420	AppImage version not set correctly
#895	AppImage .DirIcon broken
#603	Cannot run AppImage format
#1539	Push-to-talk rapidly toggles recording (X11 auto-repeat)

---

🔧 Open PRs (awaiting resolution)

Critical for Wayland + Flatpak

PR	Description	Author	Status
#689	Remote Desktop portal for Wayland (text input via portal)	@petit-aigle, @D3nis	Open — needs merge
#1287	xdg-desktop-portal GlobalShortcuts backend for Wayland	@nmcbride	Open — needs merge
#548	Flatpak packaging support	@GabeDuarteM	Open — needs review + merge
#1395	Fix Wayland paste + post-process	@vetmiker	Open — needs merge
#1299	Prefer dotool for reliable Wayland text input	@aasmall	Open
#1300	Add "None" keyboard implementation for Wayland	@aasmall	Open
#1337	Initialize Enigo on Wayland and tolerate failure	@LukeCarrier	Open
#1276	Clipboard paste methods fail on GNOME Wayland	@mrinterweb	Open
#1505	Improve GNOME Wayland overlay behavior	@Ramtx	Open
#1388	Fix window controls, dotool latency, fd leak, overlay focus	@R11manish	Open

Additional Linux PRs

PR	Description	Author	Status
#572	Wayland support with GNOME system shortcuts	@juulieen	Open
#1397	Optional GNOME Shell extension for status display	@R11manish	Open
#1455	Implement native IBus direct input engine	@ricardolee	Open
#1545	Remote desktop clipboard paste	@D3nis	Open

---

✅ Resolved issues (merged PRs)

Text insertion

PR	Description	Author
#493	Fix direct typing (wtype/dotool)	@johnmalek312
#557	Add ydotool support for text input	@manimohans
#676	Add KDE Plasma 6 Wayland support via kwtype	@datenfalke
#760	Add typing tool selector (UI)	@kakapt
#376	Add Wayland paste support via wtype/dotool	@lhotari
#281	SIGUSR2 + wayland enigo feature	@johnpyp

Hotkeys + overlay

PR	Description	Author
#354	SIGUSR2 handling for toggles	@johnpyp
#759	SIGUSR1 for transcribe_with_post_process	@arimxyer
#1121	Fix overlay problem in KDE	@vpsone
#769	Improve Wayland startup stability	@boeserwolf
#792	Add CLI parameters for Linux	@retspen
#824	Fix transcription lock-up race condition	@johnpyp

Documentation and CI

PR	Description	Author
#1426	Document Linux workarounds in Known Issues	@manato-tajiri
#1266	Add Linux startup troubleshooting section	@xilec
#951	Add Linux install steps + AppImage troubleshooting	@arimxyer
#789	Apply DMABUF workaround on all Linux systems	@suuuehgi
#748	Clarify gtk-layer-shell runtime requirements	@datenzar
#752	Install gtk-layer-shell for Ubuntu builds	@datenzar

---

🗺️ Implementation stages

Phase 1: Basic Flatpak infrastructure

• PR feat: add Flatpak packaging support #548 — Merge Flatpak packaging support (@GabeDuarteM)
• Verify Flatpak builds on CI after merge
• Resolve conflicts with main branch

Phase 2: Wayland text input (core)

- [ ] PR #1395 — Merge Wayland paste + post-process fix (@vetmiker)
- [ ] PR #1299 — Merge dotool as preferred typing tool (@aasmall)

• PR fix(linux): add 'None' keyboard implementation for Wayland compositors #1300 — Merge "None" keyboard implementation (@aasmall)
• PR fix(linux): Clipboard paste methods (ctrl_v / ctrl_shift_v / shift_insert) fail on GNOME Wayland #1276 — Merge clipboard paste fix for GNOME Wayland (@mrinterweb)
• PR fix(wayland): initialise Enigo, and tolerate failure #1337 — Merge Enigo initialization fix for Wayland (@LukeCarrier)
• PR Feat/add remote desktop direct mode on wayland #689 — Merge Remote Desktop portal for Wayland (@petit-aigle, @D3nis)
• PR Fix/remote desktop clipboard paste #1545 — Merge clipboard paste via Remote Desktop portal (@D3nis)

Phase 3: Global hotkeys on Wayland

• PR feat(linux): add xdg-desktop-portal GlobalShortcuts backend for Wayland #1287 — Merge xdg-desktop-portal GlobalShortcuts backend (@nmcbride)
• PR feat(linux): add Wayland support with GNOME system shortcuts #572 — Consider merging GNOME system shortcuts (@juulieen)
• PR Fix Linux window controls, dotool latency, HandyKeys fd leak, and overlay focus race #1388 — Merge window controls + dotool fixes (@R11manish)
• PR fix(linux): improve GNOME Wayland overlay behavior #1505 — Merge GNOME Wayland overlay improvements (@Ramtx)
• PR feat(ibus): implement robust native IBus direct input engine and sile… #1455 — Consider merging IBus native input engine (@ricardolee)

Phase 4: Regression testing

• Test all paste methods (Direct, Ctrl+V, Ctrl+Shift+V, Shift+Insert)
• Test hotkeys (toggle, push-to-talk, cancel)
• Test post-processing
• Test overlay (positioning, focus)
• Test autostart
• Test microphone and output devices
• Test long sessions (sleep/wake, lock/unlock)

Phase 5: Flatpak → Flathub

• PR feat: add Flatpak packaging support #548: Add screenshots to com.pais.handy.metainfo.xml
• PR feat: add Flatpak packaging support #548: Verify Flathub linter compliance
• Fork flathub/flathub, submit PR to new-pr branch
• Add x-checker-data for automatic version updates
• Await Flathub reviewer approval
• Setup automatic updates on new Handy releases

---

🧪 Testing matrix

By environment (DE + compositor)

Environment	Testers	Status
GNOME Wayland (Fedora, Ubuntu, Arch)	@petit-aigle @D3nis @mrinterweb @hsablonniere @delthas @bkanuka	✅ Actively tested
KDE Plasma Wayland (Fedora KDE, Bazzite, Arch, CachyOS)	@koloved @essoen @ndeybach @Gareth-Rouse @VorpalBlade	🔄 In progress
GNOME X11 (Ubuntu, Debian)	@sasha-computer @shockme	🔄 Testing needed
Sway/Hyprland (wlroots)	@aasmall @petit-aigle	🔄 Testing needed
COSMIC (Pop!_OS)	@jnials @mgabor3141	🔄 Testing needed

By distribution

Distribution	Testers	Priority
Fedora 43+ (Workstation, KDE, Atomic)	@petit-aigle @essoen @ndeybach @D3nis	🔴 High
Arch Linux / CachyOS	@mrinterweb @Nirose @VorpalBlade @delthas	🔴 High
Ubuntu 24.04+	@bkanuka @sasha-computer @shockme @arpagon	🔴 High
Bazzite / Bluefin (atomic Fedora)	@koloved	🔴 High
NixOS	@xilec @manimohans @zitongcharliedeng	🟡 Medium
Pop!_OS 24.04	@jnials	🟡 Medium
Debian / Linux Mint	—	🟢 Low
openSUSE	—	🟢 Low

Key test scenarios

• Flatpak installation and first launch
• Automatic text insertion (Direct method)
• Clipboard paste (Ctrl+V, Ctrl+Shift+V, Shift+Insert)
• Global hotkey toggle
• Push-to-talk (press/release)
• Post-processing (LLM)
• Overlay (position, focus, multi-monitor)
• System autostart
• Operation after sleep/wake
• Operation after lock/unlock
• Special characters, uppercase letters, Unicode
• Long sessions
• Version updates

---

👥 Testing team by group

🟢 GNOME Wayland

• @petit-aigle — Remote Desktop portal, input testing
• @D3nis — clipboard paste, Fedora 43 GNOME
• @mrinterweb — CachyOS/GNOME, wtype fixes
• @hsablonniere — Arch Linux/GNOME, first character root cause
• @delthas — French keyboard layout, Unicode testing
• @bkanuka — Ubuntu/GNOME, portal testing

🟣 KDE Plasma Wayland

• @koloved — Bazzite (atomic Fedora), Flatpak builds, titlebar fix
• @essoen — Fedora KDE, post-processing
• @ndeybach — Fedora 44 KDE, Flatpak testing
• @Gareth-Rouse — KDE, Direct mode
• @VorpalBlade — Arch/KDE, dotool testing
• @R11manish — window controls, dotool latency fixes

🔵 wlroots (Sway, Hyprland)

• @aasmall — dotool, "None" keyboard implementation
• @petit-aigle — Hyprland, portal testing

🟡 Distribution-specific

• @xilec — NixOS
• @zitongcharliedeng — NixOS
• @manimohans — ydotool support
• @jnials — Pop!_OS
• @shockme — Ubuntu 22.04

---

🏗️ Flathub publication stages

Step 1: Flatpak manifest preparation

• Update com.pais.handy.yaml (PR feat: add Flatpak packaging support #548 + all merged Wayland PRs)
• Set --socket=wayland as primary, --socket=fallback-x11 as fallback
• Ensure finish-args include all required portals

Step 2: Flathub metadata

• Add screenshots to com.pais.handy.metainfo.xml
• Add categories (Audio, Productivity, Utility)
• Add links to homepage, help, donation
• Validate metadata with Flathub validator

Step 3: CI/CD for automatic builds

• Setup GitHub Actions to build Flatpak on each release
• Add x-checker-data to manifest for automatic version updates

Step 4: Publication

• Fork flathub/flathub
• Create branch from new-pr
• Add com.pais.handy/ directory with manifest and metainfo
• Open PR to flathub/flathub
• Pass Flathub moderator review
• Get access to flathub/com.pais.handy

Step 5: Post-release

• Setup automatic updates on new Handy releases (Flathub bot)
• Add "Get it on Flathub" badge to README
• Update Linux installation documentation

---

📌 Merge requirements

1. Flatpak must be the primary distribution method — all new Linux fixes must be tested in Flatpak builds
2. Remote Desktop portal (Feat/add remote desktop direct mode on wayland #689) + GlobalShortcuts portal (feat(linux): add xdg-desktop-portal GlobalShortcuts backend for Wayland #1287) — minimal set for Wayland operation
3. Both GNOME and KDE support — solutions must not be tailored to a single DE
4. Backward compatibility — X11 and existing methods (wtype, dotool, ydotool) must continue working
5. Auto-detection — Handy should auto-detect available input methods and choose the optimal one

---

Created by @koloved to coordinate Wayland support efforts for Handy
Repository: https://github.com/cjpais/Handy

[koloved]

@cjpais Uh, sorry, my agent decided to publish this (using git cli ) on their own, even though I didn't ask them to. Still need to read, study, and correct all of this. I will take care of it.

[D3nis]

And keep your AI agents on a tight leash! :)

Why I Avoid Flatpak and Snap

After years of experience using both Flatpak and Snap in various Linux environments, I have made a conscious decision to completely drop them from my workflow and infrastructure.

While the idea of universal packaging and sandboxing sounds good on paper, the real-world implementation introduces too much overhead and system clutter ("bloat") that I am not willing to tolerate.

Here is why I stick to native packaging (like RPM/DEB) or building from source:

• Excessive Disk Clutter: Both formats bring gigabytes of redundant runtimes and duplicate dependencies. A tiny utility can easily pull in a 2GB base platform, leaving a lot of orphaned "garbage" over time.
• RAM and Resource Inefficiency: Isolated applications cannot efficiently share memory. Running multiple Flatpak/Snap apps results in heavy RAM duplication, which is unacceptable for clean or resource-constrained systems.
• Poor System Integration: Sandboxed applications often break system themes, fail to respect local fonts, and restrict access to essential paths like /media or /mnt without manual overrides.
• The Illusion of Security: Many packages request broad permissions (host access, X11, network) just to function properly, defeating the purpose of a sandbox while shifting the responsibility of security updates from trusted distribution maintainers to individual package creators.
• CLI Clumsiness: These formats are heavily geared towards GUI apps. Using them for command-line utilities or in server environments introduces awkward syntax and unnecessary complexity.

I prefer to keep my systems minimal, predictable, and clean. Native packages remain the superior choice for performance and control.

[koloved]

To clarify, I am not offering completely abandoning native packages or building from source. Provided it doesn't create heavy maintenance overhead for the project.

The focus on Flatpak is strictly about streamlining the installation and reducing bugs for the most common user workflows:

• One format for all: Instead of fighting the distribution "zoo", Flatpak provides a predictable baseline that works identically across Ubuntu, Arch, or Fedora.
• Atomic system support: Users on modern immutable distributions like Bazzite or SteamOS cannot easily install traditional packages.
• Negligible size: The Flatpak version of Handy is only 16 MB According to my builds of this application.
• Maintainer sanity: Troubleshooting fragmented issues across various Linux distros is simply unsustainable for a single maintainer

Focusing on Flatpak is just a pragmatic way to deliver a reliable, working app to the vast majority of users right away, without locking out those who prefer native builds.

I just want the application to work and install with one click. The extra couple of tens of megabytes it takes up on my hard drive doesn't bother me. It doesn't matter to me if an extra hundred megabytes of RAM are used to run the flatpak version.

---

_{Note: This discussion is veering into a classic package format "holy war," which unfortunately distracts from the practical goals of this issue tracker. My only priority is to make the app work smoothly and install easily for the majority of users. Instead of debating packaging philosophies, let's focus on the actual goal. XD}

[koloved]

Handy 0.8.3 — Wayland-native Flatpak build (test release)

handy_0.8.3_x86_64.flatpak.zip

This build combines several PRs and fixes to make Handy work natively on Wayland without X11 fallback. The --socket=x11 has been removed — the build is --socket=wayland only.

What's included

PR #689 — Remote Desktop text input pipeline (petit-aigle, D3nis)

• Backend logic for Wayland input via xdg-desktop-portal.RemoteDesktop
• Unicode fallback for characters missing from the active compositor keymap
• Configurable key event delay
• Portal paste shortcut support

PR #548 — Flatpak infrastructure

• Flatpak manifest & build script (scripts/build-flatpak.sh)
• Tray icon support via libayatana-appindicator
• Autostart handling for Flatpak
• Host theme/icon/font access via portals
• Color-scheme detection via org.freedesktop.portal.Settings
• Min/max/close button workaround for a Tauri issue

Portal GlobalShortcuts backend (Nathan McBride — #1287, adapted)

• New keyboard shortcut backend using org.freedesktop.portal.GlobalShortcuts
• Full push-to-talk press/release support on Wayland
• Set as default on Linux — no X11 needed for shortcuts
• Automatic fallback to Tauri if the portal is unavailable

Flatpak manifest

• D-Bus permissions for org.freedesktop.portal.Desktop, GlobalShortcuts, PermissionStore
• --socket=wayland only — X11 fully removed

Note on PR #1395 — was tried but proved unnecessary after the fixes above were applied. It also broke post-processing, so it was dropped.

How to test

handy_0.8.3_x86_64.flatpak.zip

flatpak install --user handy_0.8.3_x86_64.flatpak
flatpak run com.pais.handy

Test on KDE Plasma 6 Wayland or GNOME 48 Wayland. Switch Keyboard Implementation to XDG Desktop Portal in Settings → Debug to use the new backend.

Request to maintainers

@cjpais Please build a test build PR - #1560 ,so people can try forced-Wayland mode without X11. Early feedback on compositor compatibility would be very welcome.

My tests

• Flatpak installation and first launch
• Automatic text insertion (Direct method)
• Clipboard paste (Ctrl+V, Ctrl+Shift+V, Shift+Insert)
• Global hotkey toggle
• Push-to-talk (press/release)
• Post-processing (LLM)
• Overlay (position, focus, multi-monitor)
• System autostart
• Operation after sleep/wake
• Operation after lock/unlock
• Special characters, uppercase letters, Unicode
• Long sessions

[cjpais]

First, I just want to say thank you for this. I appreciate you helping with this effort. And I also am wondering if this is something that for Linux users we probably should be doing a better distinction in our own website and things like this, offering specific X11 and Wayland builds. And if this would simplify things overall, or if the combined version is still overall the best, I'm just kind of wondering in terms of strategy and release for the Linux community, what is the best? And certainly, I don't want to get into packaging and flame wars. We need to support as many people as possible. And that means supporting the different package managers and methodologies despite someone's preference. I don't really care what their preference is. If people are using something en masse, we need to support it

[petit-aigle]

Personally, I think keeping a single app remains the best solution.

First, a user can, in some cases, on the same machine, launch either an X11 session or a Wayland session. Most software already supports both natively. I therefore think that going against what is done in most cases is a bad idea.

Then, I think the right path is to continue in the current direction: automatically detecting the right configuration, the right environment, and then applying the appropriate configuration.

Finally, I think we should try, as much as possible, to do this without external dependencies that can be avoided or directly managed from Rust. Tools like dotool, wtype, xdotool, etc. are excellent resources to move fast and easily ensure compatibility, but for me, they should only be transitional.

In the long term, we should aim to replace them with native handling, with the right configuration for each environment, in order to automatically apply the ideal configuration for the user’s environment (automatic, no external dependency = zero friction for the user).

So, if effort has to be invested somewhere, I would lean toward organizing the code in a way that allows, in the long term, native and automatic handling of each case, as well as a clean and automated way to test the different environments (environment-specific CI/CD).

[xilec]

Replying to @cjpais's question about whether splitting X11/Wayland builds would simplify things — I'd argue against splitting the supported builds, and instead suggest one auto-detecting build + a visible "Strict Wayland" toggle. Here's the reasoning:

Why not two supported builds

• It doubles the release/CI/test matrix (AppImage × deb × flatpak × 2 variants × arches) — the opposite of the "maintainer sanity" goal.
• Users can't reliably classify their environment. A Wayland session is not X11-free: it still hosts plenty of XWayland windows (legacy apps, some Electron/games). A "pure Wayland, no X11" build risks silently regressing input/shortcuts into exactly those windows, and the user won't know why.
• It doesn't actually reduce code paths — both builds carry the same code; the "wayland" one just flips a packaging flag. The maintenance burden stays; only packaging complexity grows.

Why a runtime toggle is the better mechanism

• The real value of "no X11 fallback" is testing: with --socket=x11/XWayland present, Wayland bugs get masked because input silently falls back to the X11 path. A "Strict Wayland (disable X11 fallback)" toggle lets real users dogfood the pure path and report compositor-specific issues — without anyone having to pick the right build on the download page.
• Precedent for runtime over build-split: Firefox (MOZ_ENABLE_WAYLAND), Electron/Chromium (--ozone-platform=wayland).
• It fits @petit-aigle's direction perfectly: single binary, auto-detect as the base, with the toggle as an override.

On discoverability (the one real downside of a toggle):

• A persistent, low-key note in Advanced settings, shown only on Linux, placed after the settings list in a distinct accent color — visible enough to notice, but not a nag, and it doesn't disappear after one dismissal (unlike a first-run popup, which users reflexively close or forget).
• Promote the toggle itself out of Settings → Debug into a visible Linux / Input section with a short explanation (the current XDG Desktop Portal switch is effectively hidden in Debug).
• A documented CLI flag / env (--strict-wayland / HANDY_DISABLE_X11_FALLBACK=1) for power users and environment-specific CI.
• On the website: rather than offering a separate "Wayland" download, add a short "help us test Strict Wayland mode" request once the release with this toggle ships.

Net: same testing signal, no matrix growth, no forcing users to guess which build fits their environment — and it stays aligned with the auto-detect direction already discussed here.

[cjpais]

Okay, I'm happy to get feedback and we will not split the builds. But certainly, we need a lot of people to help test because we really don't want to break things ideally and only fix things. Also, if there's obvious places in the code base where we can have very clear logic in regards to the Linux platform handling, we should do so because by far it's the largest source of issues in this code base and we probably need to centralize some of the platform-specific handling, I think

[EmanoelDionisio]

#1568 targets two items from this meta tracker on GNOME Wayland:

• Text insertion: GNOME paste/keycombo path no longer stops at a broken `wtype`; prefers `ydotool`/`dotool` with runtime fallback (addresses [BUG] GNOME Wayland: keycombo paste selects wtype then fails with no fallback; ExternalScript paste hangs via wl-copy #1549 Problem 1).
• Hotkeys: defaults `KeyboardImplementation` to `HandyKeys` (evdev) on Linux Wayland so the recording shortcut works without Tauri global-shortcut.

Does not cover ExternalScript/`wl-copy` hang (#1549 Problem 2) or Flatpak/portal work tracked here.

[tim-seoss]

FWIW, with tauri-apps/global-hotkey#172 I have a working environment on Debian Testing via the .deb package (KDE + Wayland). That PR (adds org.freedesktop.portal.GlobalShortcuts support to Tauri) was authored in March, but doesn't seem to have had much attention. It would need enhancing to provide automatic fallback to when org.freedesktop.portal.GlobalShortcuts is unavailable to bring it up to feature parity with #1287 but otherwise it might be preferable to have an upstream solution rather than add potential future maintenance in the form of additional Handy-specific code.

[koloved]

@tim-seoss I added this tauri-apps/global-hotkey#172 PR support for all features that were a better implementation of what was initially implemented from #1287

now its here was updated to 0.9 upstream - #1560

full log

feat(portal): integrate GlobalShortcuts improvements from https://github.com/tauri-apps/global-hotkey/pull/172 Backport features from https://github.com/tauri-apps/global-hotkey/pull/172 into the XDG portal keyboard shortcut backend (portal_impl.rs): - Use crossbeam_channel::Select for multiplexing commands and portal events in a single event loop, replacing the tokio::select + sleep approach. The dedicated tokio runtime handles D-Bus calls on demand. - Portal restart recovery: detect D-Bus signal stream end (portal or compositor restart), wait 1s, recreate the session and rebind all registered hotkeys automatically. Shortcuts keep working across systemctl --user restart xdg-desktop-portal. - Rollback on bind_shortcuts failure: when register/register_batch fails, remove only the newly added hotkey IDs so a later rebind won't silently bind a broken shortcut. - Comprehensive keycode → keysym mapping (a-z, F1-F24, arrows, numpad, XF86 media keys, punctuation) replacing the simplistic capitalise- first-letter heuristic. Produces correct portal preferred triggers. - SHIFT + symbol detection: omit preferred triggers for digit and punctuation keys when SHIFT is held (their keysym depends on the keyboard layout), letting the compositor prompt the user instead. - register_host_app() via FLATPAK_ID or GLOBAL_HOTKEY_APP_ID env vars for proper desktop integration in sandboxed environments. - trigger_description() queries the portal via ListShortcuts to return the actual binding set by the compositor (users may reassign shortcuts in system settings), exposed as a new Tauri command get_portal_trigger_description. Also fix a bug where switching from HandyKeys to Portal/Tauri left the rdev keyboard listener running in a perpetual KeyboardError retry loop on Wayland: - Add HandyKeysState::shutdown() (stop recording → send Shutdown to manager thread → join thread → HotkeyManager drops → rdev stops). - Call shutdown() in change_keyboard_implementation_setting before unregistering shortcuts from the old implementation. - Add HandyKeysState::is_alive() and use it in the rollback re-init check so switching back to HandyKeys re-creates the state correctly after a prior shutdown. Backport features from https://github.com/tauri-apps/global-hotkey/pull/172 into the XDG portal keyboard shortcut backend (portal_impl.rs):

• Use crossbeam_channel::Select for multiplexing commands and portal
  events in a single event loop, replacing the tokio::select + sleep
  approach. The dedicated tokio runtime handles D-Bus calls on demand.

• Portal restart recovery: detect D-Bus signal stream end (portal or
  compositor restart), wait 1s, recreate the session and rebind all
  registered hotkeys automatically. Shortcuts keep working across
  systemctl --user restart xdg-desktop-portal.

• Rollback on bind_shortcuts failure: when register/register_batch
  fails, remove only the newly added hotkey IDs so a later rebind
  won't silently bind a broken shortcut.

• Comprehensive keycode → keysym mapping (a-z, F1-F24, arrows, numpad,
  XF86 media keys, punctuation) replacing the simplistic capitalise-
  first-letter heuristic. Produces correct portal preferred triggers.

• SHIFT + symbol detection: omit preferred triggers for digit and
  punctuation keys when SHIFT is held (their keysym depends on the
  keyboard layout), letting the compositor prompt the user instead.

• register_host_app() via FLATPAK_ID or GLOBAL_HOTKEY_APP_ID env
  vars for proper desktop integration in sandboxed environments.

• trigger_description() queries the portal via ListShortcuts to
  return the actual binding set by the compositor (users may reassign
  shortcuts in system settings), exposed as a new Tauri command
  get_portal_trigger_description.

Also fix a bug where switching from HandyKeys to Portal/Tauri left the
rdev keyboard listener running in a perpetual KeyboardError retry loop
on Wayland:

• Add HandyKeysState::shutdown() (stop recording → send Shutdown to
  manager thread → join thread → HotkeyManager drops → rdev stops).
• Call shutdown() in change_keyboard_implementation_setting before
  unregistering shortcuts from the old implementation.
• Add HandyKeysState::is_alive() and use it in the rollback re-init
  check so switching back to HandyKeys re-creates the state correctly
  after a prior shutdown.