..but why?
My employer asked us TAM’s in Japan to fetch our belongings from the office, so I got home with the keyboard I bought in Korea, with Korean Hangul - and 3 big places of rust.
I made a weekend project to remove the rust and repaint, worked ok. Then: hooking it up to my Thinkpad, currently running KDE Plasma. Basic configuration worked ok, Plasma was coping with the Thinkpad having German layout and the Koran one having English layout, plus extra keys. But then, I tried to configure keys for changing the virtual screen, and was not able to do that. The error was about the focus being configured to follow the mouse, while the desired key combination was not compatible to that. After 30 min of trying around I gave up.
There are further points about Plasma for me: after initial installation via Fedora package group, I also had a search engine installed which took down performance as it indexed by complete homedir- I do not need that, I can search my files directly when needed, and then more targetted than a search/index machine can do. Also, things like attaching the mp3 player by default opening a window and offering actions - no, I am fine with doing a plain ‘mount /mnt/walkman’ then as user, and moving the new podcasts around on the shell. Things like this make me wonder if Plasma is doing more handholding than I need.
Sway!
I was running sway since quite some time on the company provided Thinkpad, but now it became my main driver on the private Thinkpad L480. The basic config ~/.config/sway/config was copied over from the company system. Configuring the external keyboard took just 5min, including the key bindings to move to next/previous virtual screen.
When I started Plasma, it took quite some seconds, Sway in contrast is small and quick. With Plasma, I started to execute gkrellm, which shows stats like cpu/network load, then I started terminal instances, and moved them around with the mouse to always the same sizes and places on the screen.
With Sway, I have currently just the most important monitors, and directly in the status bar at the top: network bandwith in/out, cpu load, consumed memory, fan rotation, battery charge level, time. As Sway is tiling, when opening the first terminal it consumes the whole screen. Opening the second terminal, both get equal shares of the screen by default. So effectively, I spend less time of changing sizes of windows than I did on Plasma.
Current painpoints
I live in Japan, and the default Input Method framework on Fedora/RHEL would be ibus, but due to a bug, it is not yet usable on Sway. fcitx works reasonably well.
Biggest issue is screen sharing with video chat software. So far I used Plasma with Xorg, and all of Skype (native Linux application), Bluejeans, Jitsi, Google meet (all services usable via Firefox or Chrome) were able to grab the whole screen and share it in the video confcall. Sway is Wayland based, and apparently whole screen sharing is not yet possible.
Is that important at all? For me, yes. I have sessions with colleagues or Japanese schools where it’s easiest to just share the screen, then together do an internet search, or I run ‘dia’ (an OpenSource diagram software) and draw up something to underline an explanation. Or I just share the screen and then run an image viewer to show family members pictures taken in the last week.
So what to do on Sway for this? So far, I came up with 2 workarounds:
- using v4l2loopback and wf-recorder to record the current screen,
and make it available as device, for example /dev/video0. That
can then be chosen as webcam, and transmits the screen.
- pro: transmits the full screen, when I change to other virtual screens, it follows
- con: it puts quite some load onto the system
- con: seems mostly to be presented with bad quality at clients
- second method, webtops container.
This basically runs a window manager in a container, and you
access that desktop via web browser - and as Chrome and many
video chat softwares allow sharing of browser tabs, this
allows sharing with the others.
- con: requires to setup and run an extra container
- con: whatever you want to do, you need to do it in that container instead of your normal desktop. So might require installation of extra packages there, etc.
- pro: less cpu load than above workaround
- pro: good quality for the client
My Sway notes and hints are here in the wiki.
Next steps
I’m now in the market for looking again at terminal emulators. Using xterm since many years, I did do far not manage to get URLs in xterm clickable, so that double-click of one character of https://example.org marks the whole URL, copies it into the buffer and opens it. Also increasing/decreasing font size would be nice, and as I also use irssi (IRC client) and mutt (mail client) from the terminal, I need it to deal properly with unicode and Japanese fonts. ’terminator’ looks like a good candidate.
Let’s see how it goes!
Last modified on 2021-11-07