eframe: use the activation token from the environment on window creation - #8406
Open
Le-Syl21 wants to merge 2 commits into
Open
eframe: use the activation token from the environment on window creation#8406Le-Syl21 wants to merge 2 commits into
Le-Syl21 wants to merge 2 commits into
Conversation
…reation A desktop entry with `StartupNotify=true` hands the application a token through `XDG_ACTIVATION_TOKEN` (Wayland) or `DESKTOP_STARTUP_ID` (X11), and winit can only apply one at window creation (`WindowAttributesExtStartupNotify::with_activation_token`). eframe never read it, so the first window opened without it. On a compositor that enforces focus-stealing prevention that is not a cosmetic loss: the window opens unfocused and cannot recover, since `ViewportCommand::Focus` is precisely the request being refused. Measured on a pinball cabinet under Mutter — the launcher stayed unfocused from startup until the user clicked it, which also cost it the pointer constraint (a compositor only grants one to a focused surface), so the mouse could neither be confined nor move the cursor. The variables are cleared once read, per the startup-notification spec: a token is single-use, and leaving it in the environment would have every later viewport, and every child process, replay it.
|
Preview available at https://egui-pr-preview.github.io/pr/8406-activation-token-from-env View snapshot changes at kitdiff |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A desktop entry with
StartupNotify=truehands the launched process an activation token throughXDG_ACTIVATION_TOKEN(Wayland) orDESKTOP_STARTUP_ID(X11). winit can apply one, but only at window creation, viaWindowAttributesExtStartupNotify::with_activation_token. eframe never reads it, so the token our launcher went to the trouble of issuing is thrown away.winit's own docs are blunt about the consequence:
That is what I ran into: under Mutter the window opens unfocused and cannot recover, since
ViewportCommand::Focusis precisely the request focus-stealing prevention blocks. On a kiosk-style setup the cost goes past a missing title-bar highlight — a compositor only grants a pointer constraint to a focused surface, soCursorGrabsilently does nothing too.This reads the variable when building the window attributes and passes it to winit. The environment is cleared afterwards through winit's
reset_activation_token_env(), per the startup-notification spec: a token is single-use, and leaving it around would have every later viewport, and every child process, replay it.Linux only, behind the existing
wayland/x11features; a no-op when the variables are absent.