ExtremeDullard

To configure several keyboard input layouts, it's quite simple - especially if you come from i3: no need for ibus or fcitx (both bring their own problems in Sway/Wayland).

All you have to do is edit your keyboard input preferences right in your Sway config file. For example:

input type:keyboard {
        xkb_layout us,fr,fi,es
        xkb_options grp:alt_space_toggle,lv3:ralt_switch
}

This sets up 4 keyboard layout (US, French, Finnish and Spanish) and Alt+space as the shortcut to cycle through them.

There's a plethora of XKB layouts and options. You can see them all by doing man xkeyboard-config. Pick the ones you want.

Then if you use Waybar, you can set it up so that it displays the layout currently in use with the sway/language module. For instance, put this in your Waybar config file:

"sway/language": {                                                           
    "format": "{flag}",                                                      
    "tooltip": false,                                                        
    "on-click": "swaymsg input type:keyboard xkb_switch_layout next",        
    "on-click-right": "swaymsg input type:keyboard xkb_switch_layout prev"   
},                                                                         

This shows the current layout as the corresponding country flag and configures left- and right-click to cycle through the layouts when clicking on the flag.

Finally, if you like to type emojis and you don't want to remember the unicode numbers (which you can enter in hexadecimal with Ctrl+Shift+u in case you didn't know), install rofimoji and wtype: rofimoji is a very nice Rofi-based emoji picker, and wtype is the Wayland typer it needs to inject the emojis through the Wayland virtual keyboard:

Then add a key binding in your Sway config file to call the emoji picker. I personally use Ctrl+Shift+e:

bindsym Ctrl+Shift+e exec rofimoji

Final twist: if you use several input layouts and you display the current layout in Waybar, you'll notice that wtype (called by rofimoji) makes the Waybar language icon disappear.

That's because there's a bug in the Waybar Sway language module: it doesn't mess up the keyboard input, it just makes the icon disappear until you change the layout, and then it comes back.

So here's a workaroud, since nobody seems to be in a hurry to fix this bug 😃:

• In .local/bin, create a wtype file with the following content:

#!/bin/sh
/usr/bin/wtype $@ && swaymsg input type:keyboard xkb_switch_layout next && swaymsg input type:keyboard xkb_switch_layout prev

What this script does is call the real wtype, then switch the keyboard layout back and forth to make the Waybar language icon reappear.

• Add .local/bin to your PATH environment variable BEFORE /usr/bin, so your wtype wrapper is called by rofimoji in lieu of the real wtype. To do that in Sway:

  • Add the modified PATH to ~/.config, e.g.:

  PATH=$HOME/.local/bin:$PATH
  

  • call systemctl --user daemon-reload
  • Log out and back in

  (if you wonder why you have to do all this to set a simple environment variable in Sway, see here)

After that, the language icon should stay put when you enter emojis.

Now you can pay your McMansion with McDollars and help bring about the next subprime mortgage crisis.

Don't tourists know by now that visiting the US in 2025 is like visiting Germany in 1938?

Today was rough. It hasn't been this intense for at least a year.

This man's homemade prostheses are awesome!

Check out his creations on his Tiktok and his Youtube channels.

I particularly like his super-cheap prostheses made out of plastic soda bottles, a technique we mentioned here before.

The following two key bindings will add simple screen recording hotkeys:

• Mod+Shift+Alt+F11 records a region or the full screen to ~/Videos/screen_capture.mp4
• Mod+Shift+Alt+F12 records a region or the full screen to ~/Videos/screen_capture.mp4 with the audio output.

bindsym $mod+Shift+Alt+F11 exec pkill wf-recorder && notify-send "Video captured in ~/Videos/screen_capture.mp4" || wf-recorder -y -g "$(slurp)" -f ~/Videos/screen_capture.mp4
bindsym $mod+Shift+Alt+F12 exec pkill wf-recorder && notify-send "Video with audio output captured in ~/Videos/screen_capture.mp4" || wf-recorder -y -g "$(slurp)" -f ~/Videos/screen_capture.mp4 -a=alsa_output.platform-analog-sound.stereo-fallback.monitor

Hit the key combo, select the whole screen or the region you want to record, then hit the key combo again to stop the recording.

You need to install wf-recorder, slurp and notify-send for those key bindings to work.

In addition, for the Mod+Shift+Alt+F12 binding, you need Pulseaudio or Pipewire to capture the audio sink's monitor, and you probably need to find out what name it has on your system and replace the name after -a=

To figure out the name of the monitor, simply list the audio sources on your system:

$ pactl list sources | grep Name
	Name: alsa_output.platform-analog-sound.stereo-fallback.monitor
	Name: alsa_input.platform-analog-sound.stereo-fallback

Naturally, you can use any other source you want - your microphone for example if you want to talk over the screen capture.

KDE Connect is a fantastic tool to integrate your cellphone with your desktop. But while it generally works well, it has a few issues in Sway.

Here's a quick overview of how to make it work correctly.

First of all, you need to start the KDE Connect daemon when the session opens. No biggie, it's just a regular config line:

exec QT_QPA_PLATFORM=xcb kdeconnectd

The KDE Connect runs silently in the background. You can tell if it's working properly by trying to list devices it sees around on the network:

$ kdeconnect-cli -l
- Fairphone4:  (paired and reachable)
- lloyd@november: _24be2fd9_7c47_47de_a454_618bb6e0e016_ (reachable)
- rosco@alfa: _508af911_1c83_4b3b_af01_7e2ca78c776a_ (reachable)
3 devices found

Then you want to run the KDE Connect indicator in the system tray. You can try to run the KDE Connect-supplied indicator program from the Sway config file by adding this line after starting the daemon:

exec kdeconnect-indicator

If it works for you, great! You're done with that.

Unfortunately, I find that it doesn't play so nicely with Waybar. It works 75% of the time, but it regularly fails to show up in my system tray - as in, it runs okay, but the icon is missing, which kind of defeats the purpose.

If this happens to you too, you're in luck: a kind soul has written a simple Python replacement that works great. You can download it here:

https://github.com/juanramoncastan/xfconnect-indicator/tree/main

No need to clone the repo, you just need the Python script here and the two icons here and here.

• Copy xfconnect-indicator.py in /usr/local/bin
• Copy xfconnect-icon.svg and xfconnect-icon-disconnected.svg in /usr/share/icons

Then replace the kdeconnect-indicator startup line above in your Sway config file with:

exec --no-startup-id (sleep 1 && xfconnect-indicator.py) || (sleep 1 && xfconnect-indicator.py) || (sleep 1 && xfconnect-indicator.py) || (sleep 1 && xfconnect-indicator.py) || (sleep 1 && xfconnect-indicator.py)

Why this convoluted line you ask?

Because xfconnect-indicator.py fails with an exception if the KDE Connect daemon isn't running instead of retrying to connect. This ensures Sway tries to start it 5 times with a 1 second delay when it starts, giving the KDE Connect daemon time to start on its own.

The xfconnect-indicator icon should appear in the system tray reliably, and the functionalities are identical to kdeconnect-indicator.

Finally, arguably the most useful bit of KDE Connect won't necessarily work quite right for you: the sftp plugin, aka the "Browse remote" option in the indicator, that lets you browse your cellphone's files with the file manager.

In KDE, Gnome or Cinnamon, this is usually well integrated (particularly in KDE naturally): when you click on "Browse remote", Dolphin, Nautilus or Nemo appears and you can browse your cellphone's storage.

In Sway, not so much.

Most likely, if you hit "Browse remote", your default browser will open with a funky-looking kdeconnect://<uuid> URI that it won't know what to do with.

To fix this problem, create this shell script somewhere in your home directoy. I usually put all my scripts in ~/scripts and I called this one nautilus_kdeconnect_browse_remote.sh. It opens Nautilus but any file manager should work. Feel free to do your own thing instead 😃

#!/bin/sh                             
DIR=${XDG_RUNTIME_DIR}/$(echo $1 | sed -e "s/kdeconnect:\/\///")/storage/emulated/0
nautilus --new-window ${DIR}

This script extracts the UUID from the kdeconnect:// URI and uses it to work out the mountpoint / sub-directory corresponding to your cellphone's internal storage, where KDEConnect has mounted the SSHFS filesystem - usually /run/user/<your userid>/<uuid>/.

You can test it by calling it with the funky URI in your browser as argument: Nautilus should open at the right directory and you should see your cellphone's files.

Then you need to make a .desktop file for the shell script, so xdg knows what to do with it. To do this, create the file ~/.local/share/applications/nautilus_kdeconnect_browse_remote.desktop with the following content:

[Desktop Entry]
Name=nautilus_kdeconnect_browse_remote.sh
Comment=Open Nautilus at the right location when passed a kdeconnect://<uuid> URI
Exec=/home/ppc/scripts/nautilus_kdeconnect_browse_remote.sh
Type=Application
MimeType=x-scheme-handler/kdeconnect

You can validate that the .desktop file is correct by doing:

desktop-file-validate ~/.local/share/applications/nautilus_kdeconnect_browse_remote.desktop

Finally, register your .desktop file as the default handler for the kdeconnect:// scheme by adding this to your ~/.config/mimeapps.list (create the file if it doesn't exist):

[Default Applications]                                                           
x-scheme-handler/kdeconnect=nautilus_kdeconnect_browse_remote.desktop;

Check that it all works by trying to open the funky URI with xdg-open - which is really what KDE Connect does:

$ xdg-open kdeconnect://02bb6f9f_5907_4b00_ee73_8d439a9e6451

Nautilus should open at the correct directory now, instead of the browser:

And of course, the same should happen when you hit "Browse remote" too.