mirror of
https://github.com/swaywm/sway.git
synced 2024-11-28 10:51:28 +00:00
Extended info on activation environments.
parent
4166ebab82
commit
5b8ab0e37e
26
Home.md
26
Home.md
|
@ -550,10 +550,28 @@ bindsym $mod+shift+ctrl+m mode $mode_move_all_workspace_windows
|
|||
|
||||
### XDG_CURRENT_DESKTOP environment variable is not being set
|
||||
|
||||
Some applications may rely on the `XDG_CURRENT_DESKTOP` environment variable to be set so that the application can accommodate for being ran under sway. One example of this is using Screensharing in Firefox. To set this variable, one option is to modify your shell's profile file to export this environment variable before manually running `sway`. If you use a login manager, the login manager will use the DesktopNames attribute inside the `sway.desktop` file. This file may be modified to add `DesktopNames=sway`.
|
||||
Some applications and desktop mechanisms may rely on the `XDG_CURRENT_DESKTOP` environment variable to be set so that the application can accommodate for being ran under sway. Examples include XDG autostart implementations, screensharing in Firefox and many others. Sway itself does not set this variable, it should be set before sway is started. If sway is started from shell profile, export it before sway invocation. If you use a login manager, the login manager will use the DesktopNames attribute inside the `sway.desktop` file. This file may be modified to add `DesktopNames=sway`.
|
||||
|
||||
It's not good practice for applications to make use of XDG_CURRENT_DESKTOP in this way, and Firefox has an issue open to try to fix it. Refer to [xpdw's FAQ](https://github.com/emersion/xdg-desktop-portal-wlr/wiki/FAQ#how-do-i-run-xdpw) and [xdpw's Troubleshooting guide](https://github.com/emersion/xdg-desktop-portal-wlr/wiki/%22It-doesn't-work%22-Troubleshooting-Checklist) if your issue is specifically related to screensharing.
|
||||
|
||||
### Systemd and dbus activation environments
|
||||
|
||||
Some variables need to be exported to systemd and/or dbus activation environments so tools that rely on them work properly. The essential ones are:
|
||||
`WAYLAND_DISPLAY`, `DISPLAY` (if XWayland is used), `XDG_CURRENT_DESKTOP`, plus Sway's: `SWAYSOCK`, `I3SOCK`, `XCURSOR_SIZE`, `XCURSOR_THEME`.
|
||||
|
||||
Export should be performed from context of running sway process, via exec statements in sway's configuration:
|
||||
|
||||
```
|
||||
exec systemctl --user import-environment WAYLAND_DISPLAY DISPLAY XDG_CURRENT_DESKTOP SWAYSOCK I3SOCK XCURSOR_SIZE XCURSOR_THEME
|
||||
```
|
||||
|
||||
If `dbus-broker` dbus implementation is used, that's it. It reuses activation environment of systemd.
|
||||
|
||||
If classic `dbus` implementation is used, it requires updating its own separate environment:
|
||||
|
||||
```
|
||||
exec dbus-update-activation-environment WAYLAND_DISPLAY DISPLAY XDG_CURRENT_DESKTOP SWAYSOCK I3SOCK XCURSOR_SIZE XCURSOR_THEME
|
||||
```
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
|
@ -752,11 +770,7 @@ Adjust the paths so that they point to a valid location on your system.
|
|||
|
||||
This is due to GTK+ waiting for `xdg-desktop-portal` to start via D-Bus. This times out because the D-Bus activated service doesn't know what `WAYLAND_DISPLAY` to connect to.
|
||||
|
||||
This can be fixed by adding the following to your configuration file:
|
||||
|
||||
```sh
|
||||
exec dbus-update-activation-environment --systemd DISPLAY WAYLAND_DISPLAY SWAYSOCK
|
||||
```
|
||||
See [Systemd and dbus activation environments](#systemd-and-dbus-activation-environments)
|
||||
|
||||
Alternatively, set `GTK_USE_PORTAL=0` in your environment.
|
||||
|
||||
|
|
Loading…
Reference in a new issue