Repository: alacritty/alacritty (language: rust)

Issue:
Alacritty on GNOME takes some time to show up in the application switcher
When starting Alacritty via the pinned dock icon or via GNOME search it starts immediately, but it takes some time (~ 20 seconds) until it is being shown in the application switcher and in the dock (via the dot below the pinned icon).

According to [this issue on the GNOME Gitlab](https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4920) instance there is a certain API (startup_notification/xdg_activation) which needs to be used to tell GNOME that an application has been started.

Could this be the issue why this happens?

### System

OS: Linux
Version: alacritty 0.13.2 (bb8ea18e)
Linux/BSD: GNOME 47 Wayland

### Logs

```
[0.000000852s] [INFO ] [alacritty] Welcome to Alacritty
[0.000045055s] [INFO ] [alacritty] Version 0.13.2 (bb8ea18e)
[0.000052068s] [INFO ] [alacritty] Running on Wayland
[0.000265098s] [INFO ] [alacritty] Configuration files loaded from:
                                     "/home/puresick/.config/alacritty/alacritty.toml"
[0.057745546s] [INFO ] [alacritty] Using EGL 1.5
[0.057792494s] [DEBUG] [alacritty] Picked GL Config:
                                     buffer_type: Some(Rgb { r_size: 8, g_size: 8, b_size: 8 })
                                     alpha_size: 8
                                     num_samples: 0
                                     hardware_accelerated: true
                                     supports_transparency: Some(true)
                                     config_api: Api(OPENGL | GLES1 | GLES2 | GLES3)
                                     srgb_capable: true
[0.110836055s] [DEBUG] [crossfont] Loaded Face Face { ft_face: Font Face: Bold, load_flags: TARGET_LIGHT, render_mode: "Lcd", lcd_filter: 1 }
[0.114040138s] [INFO ] [alacritty] Window scale factor: 1
[0.116396030s] [DEBUG] [alacritty] Loading "Sligoil" font
[0.117666073s] [DEBUG] [crossfont] Loaded Face Face { ft_face: Font Face: Micro, load_flags: TARGET_LIGHT, render_mode: "Lcd", lcd_filter: 1 }
[0.119111275s] [DEBUG] [crossfont] Loaded Face Face { ft_face: Font Face: Micro, load_flags: TARGET_LIGHT, render_mode: "Lcd", lcd_filter: 1 }
[0.120267725s] [DEBUG] [crossfont] Loaded Face Face { ft_face: Font Face: Micro, load_flags: TARGET_LIGHT, render_mode: "Lcd", lcd_filter: 1 }
[0.121270146s] [DEBUG] [crossfont] Loaded Face Face { ft_face: Font Face: Micro, load_flags: NO_BITMAP | TARGET_LIGHT, render_mode: "Lcd", lcd_filter: 1 }
[0.123733829s] [INFO ] [alacritty] Running on AMD Radeon Graphics (radeonsi, renoir, LLVM 18.1.8, DRM 3.57, 6.10.10-arch1-1)
[0.123748557s] [INFO ] [alacritty] OpenGL version 4.6 (Core Profile) Mesa 24.2.3-arch1.1, shader_version 4.60
[0.123757614s] [INFO ] [alacritty] Using OpenGL 3.3 renderer
[0.131052734s] [DEBUG] [alacritty] Enabled debug logging for OpenGL
[0.131134397s] [DEBUG] [alacritty] Filling glyph cache with common glyphs
[0.140909972s] [INFO ] [alacritty] Cell size: 10 x 19
[0.140938456s] [INFO ] [alacritty] Padding: 8 x 12
[0.140944778s] [INFO ] [alacritty] Width: 2560, Height: 1373
[0.140973752s] [INFO ] [alacritty] PTY dimensions: 71 x 254
[0.144977245s] [INFO ] [alacritty] Initialisation complete
[0.148962924s] [INFO ] [alacritty] Font size changed to 16.0 px
[0.148984415s] [INFO ] [alacritty] Cell size: 10 x 19
[0.153487355s] [INFO ] [alacritty] Padding: 8 x 12
[0.153514736s] [INFO ] [alacritty] Width: 2560, Height: 1373
[0.154295391s] [DEBUG] [crossfont] Loaded Face Face { ft_face: Font Face: Regular, load_flags: TARGET_LIGHT, render_mode: "Lcd", lcd_filter: 1 }
[0.165655890s] [DEBUG] [alacritty_terminal] Ignoring unknown mode 7727 in set_private_mode
[0.165695525s] [DEBUG] [alacritty_terminal] Ignoring unknown mode 7727 in set_private_mode
```



Discussion / hints:
> Could this be the issue why this happens?

That sounds about right, but it's not something I'm interested in implementing.
Keep in mind that we support being `Activated` if the variable is set, activating ourselves sounds a bit strange. We can kind of activate ourselves, but that sounds a bit strange...

Also, if you do `printf "\a"` does it fix itself?
@chrisduerr That is unfortunate. Thanks for confirming that this might be the right direction.

@kchibisov While executing `printf "\a"` did not work, setting the `XDG_ACTIVATION_TOKEN` environment variable did the trick.

On fish shell I did execute the following:

```fish
set -x XDG_ACTIVATION_TOKEN; alacritty
```

This launched alacritty and it immediately appeared in the applicatio switchter.
Now since this works as a proof of concept, doing it in a clean way "from the outside" is not that straightforward.

[Reading about XDG Activation](https://wayland.app/protocols/xdg-activation-v1), there is a dedicated token which needs to be requested and used. It is not possible for an end user to do so since GNOME handles them automatically. In addition the environment variable should be unset once the application has been activated, but that is something which could be handled by a small script or similar.

I do not want to convince you to implement this, just leaving this information here for other people who might stumble across the same issue.
>[Reading about XDG Activation](https://wayland.app/protocols/xdg-activation-v1), there is a dedicated token which needs to be requested and used. It is not possible for an end user to do so since GNOME handles them automatically. In addition the environment variable should be unset once the application has been activated, but that is something which could be handled by a small script or similar.

The launcher should set it for us, so gnome in this case. If it's not set, I'm not sure what to do. We already read the variable from the environment.

Like we support being activated and state in the profile that we can be activated, it's just, if we don't we don't have the `XDG_ACTIVATION_TOKEN` set.

See https://github.com/alacritty/alacritty/blob/master/alacritty/src/display/window.rs#L151

You can probably run with `-vvv` and see if launching from the gnome launcher logs the token, if not, then it's not our problem, but rather the launcher should set it.

I remember asking them whether we should activate ourselves, but given that the `printf \a` doesn't do much, likely not? Though, one could try to activate right from the startup....

Fix patch:
diff --git a/CHANGELOG.md b/CHANGELOG.md
index dc858911b81..659a098e61a 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -44,6 +44,7 @@ Notable changes to the `alacritty_terminal` crate are documented in its
 - Cursor color requests with default cursor colors
 - Fullwidth semantic escape characters
 - Windows app icon now displays properly in old alt+tab on Windows
+- Alacritty not being properly activated with startup notify
 
 ## 0.13.2
 
diff --git a/alacritty_terminal/src/tty/mod.rs b/alacritty_terminal/src/tty/mod.rs
index 2bcc5da9972..eed2a76dc28 100644
--- a/alacritty_terminal/src/tty/mod.rs
+++ b/alacritty_terminal/src/tty/mod.rs
@@ -98,10 +98,6 @@ pub fn setup_env() {
 
     // Advertise 24-bit color support.
     env::set_var("COLORTERM", "truecolor");
-
-    // Prevent child processes from inheriting startup notification env.
-    env::remove_var("DESKTOP_STARTUP_ID");
-    env::remove_var("XDG_ACTIVATION_TOKEN");
 }
 
 /// Check if a terminfo entry exists on the system.
diff --git a/alacritty_terminal/src/tty/unix.rs b/alacritty_terminal/src/tty/unix.rs
index 8084a753b23..6565f20b8d9 100644
--- a/alacritty_terminal/src/tty/unix.rs
+++ b/alacritty_terminal/src/tty/unix.rs
@@ -227,6 +227,10 @@ pub fn from_fd(config: &Options, window_id: u64, master: OwnedFd, slave: OwnedFd
         builder.env(key, value);
     }
 
+    // Prevent child processes from inheriting linux-specific startup notification env.
+    builder.env_remove("XDG_ACTIVATION_TOKEN");
+    builder.env_remove("DESKTOP_STARTUP_ID");
+
     unsafe {
         builder.pre_exec(move || {
             // Create a new process group.


Test patch: