swaywm

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/bash
DIR=/run/user/$(id -u)/$(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.

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.

The typical Sway config file has a key binding to pop a nagging message to exit the session, like this one:

bindsym $mod+Shift+e exec swaynag -t warning -m 'You pressed the exit shortcut. Do you really want to exit sway? This will end your Wayland session.' -b 'Yes, exit sway' 'swaymsg exit'

But it's annoying because if you hit mod+shift+e accidentally, you have to go and click on the X to dismiss the nag. Weirdly, it happens to me a lot more than it should.

Here's a slightly jazzed up keybinding you might like:

bindsym $mod+Shift+e exec pkill swaynag || (swaynag -t warning -m 'You pressed the exit shortcut. Do you really want to exit sway? This will end your Wayland session.' -b 'Yes, exit sway' 'swaymsg exit' & sleep 5 && pkill swaynag)

This adds two things:

• If you hit mod+shift+e accidentally, hit it again to dismiss the nag.
• Wait 5 seconds and the nag will disappear on its own anyway.

Flameshot is arguably the best Linux screenshot utility out there. Unfortunately, it has a really annoying issue: copy-to-clipboard doesn't work in Wayland. Everything else works just great, but only being able to save screenshots to files totally breaks my workflow.

Fortunately, there's a way around this: Flameshot also has a --raw command line argument that makes it send whatever it captures to stdout. That means it's really easy to pipe it to wl-copy to send the content to the Wayland clipboard.

Here are a couple of key bindings that exploit this and make Flameshot work great in Sway:

bindsym $mod+Alt+F11 exec bash -c 'flameshot gui --raw 2> >(grep aborted || notify-send "Screenshot copied to the clipboard") | wl-copy'
bindsym $mod+Alt+F12 exec flameshot screen --raw | wl-copy && notify-send 'Screeshot copied to the clipboard'

Those command do require notify-send to be installed, which is supplied by different packages depending on your particular Linux distro. Debian has it in the libnotify-bin package.

If you don't want to install it, you can strip the fancy scripting and just define those two key bindings instead:

bindsym $mod+Alt+F11 exec flameshot gui --raw | wl-copy
bindsym $mod+Alt+F12 exec flameshot screen --raw | wl-copy

They work just as well, but they don't notify you when the screenshot is copied to the clipboard or aborted, which can be disconcerting.

This is Sway running on my ARM64 laptop. It took some effort to get everything going just right in Wayland but now that it\s all setup, I really like it.

The one thing I miss in Sway / Waybar is the ability to bind mouse and scroll events to commands when they happen in the empty parts of the bar like in i3 / i3blocks. If anybody knows how to achieve that, I'd be extremely grateful!

If you're new to Wayland as I am, you haven't failed to be frustrated by the greeter / Sway not sourcing any of the usual X or profile configuration files. In i3, you export your variables in .profile and they're set everywhere for the whole session. Not so in Sway.

That means if you have a custom PATH or some exported variable you would like to define session-wide - setting QT_QPA_PLATFORMTHEME so all QT apps use the correct theme in Gnome for instance - you can't. Not the usual way anyway.

Those variables are set if you run a terminal with the shell in login mode, if they're defined in /etc/profile or .profile, but not if you run the program directly in Sway, such as wofi / rofi for example, or any program that needs an environment variable that isn't set.

Here's how to set environment variables for the entire session in Sway:

• Choose a greeter that understands systemd's environment.d. Unfortunately, there aren't very many. GDM and Plasma are the only two that I know of that do.

• Define your environment variables in ~/.config/environment.d/envvars.conf. You can define them the usual way like in profile, including extending variables like $PATH, e.g.:

  QT_QPA_PLATFORMTHEME=qt5ct
  PATH=$PATH:/usr/games:~/scripts
  

• Either reboot for the changes to take effect, or run systemctl --user daemon-reload to get systemd to parse your file again, then log out and back in as with Xorg.

Unfortunately, simply logging out and back in without informing systemd of your changes isn't enough - which is why you need to reboot if you don't do the daemon-reload command.

That's it!

Not too obvious, and not great. But in fairness, it's no more confusing than the mess of shell and X configuration files that existed before systemd and Wayland. It's just that systemd and Wayland are an entirely different complete trainwreck that takes getting used to 😃

You've got multiple monitors and watch to switch to a window several windows away.

You could switch focus there with a number of arrow key movements.

"sway-easymotion" allows you to use to press a key that prints a one or two character label on each window. Press that key and your focuses switch there.

Over the weekend I submitted patches for a couple of new features. First, I added multi-monitor support. Second, I added a visual confirmation of which window was selected.

If you are familiar with Github and Rust, you can review the patches and try them out here:

https://github.com/edzdez/sway-easyfocus/pulls

More about sway-easyfocus: https://github.com/edzdez/sway-easyfocus

cross-posted from: https://lemmy.world/post/29689984

I use i3. I have a machine coming that only work with Wayland, so I'll be installing Sway on it.

I know Sway is touted to be a drop-in replacement for i3, but the more I think about it, the more I wonder how much of this is true.

Like for example, all the key bindings use X11 keysym names. Or the window properties likes Class and Title are also X11-specific. Surely none of this applies to Wayland, correct?

I recently upgraded from an RX 570 to an RX 6600. Everything is working great, except that the font in my menu program Fuzzel as well as the font in my terminal foot is really big on one monitor and the correct size on the other monitor. I thought it might be because the monitor with the big text had a displayport to hdmi adapter, but I switched that monitor to hdmi and the other monitor to dp, and the same monitor still had big font in the menu and the terminal. The scaling seems to be correct, both monitors seem to be identical. What is going on? Any ideas? I'm running Debian Bookworm. I also installed the amd drivers as instructed on the Debian Wiki.

Thanks

cross-posted from: https://lemmy.world/post/26945293

cross-posted from: https://lemmy.world/post/26517981

I've been suggested to use a tiling window manager like Sway since it allows for controlling windows with hotkeys, but I'm having trouble getting started. I installed it in Fedora and tried logging back in with SwayFX (since it has features like blurring) but after I'm just shown a wallpaper with a top bar, the top left shows a 1 and the top right shows the time. I don't know what to do there. I tried looking up guides but didn't find anything, can you link me some if you know of any?

cross-posted from: https://lemmy.world/post/24599872

I love i3wm and would like to switch to sway for the advantages of not using xorg. But is it worth it with a laptop that has an old nividia/intel hybrid video card? I had read that it was complicated to use nvidia cards with wayland

I miss the keyboard friendliness of HUDs and how you could search the menu quickly.

I was wondering if anyone had a wofi/rofi or equivalent HUD for sway.

Back in the day there was plotinus. So far I can't get plasmahud, gnomehud, rofihud or others to work.