I’ve installed KDE on Qubes 4.2 (with all the latest updates) but have encountered a lot of bugs. Here are the ones I haven’t been able to solve yet (some others I’ve already figured out):
My keyboard layout switcher only affects dom0. Guest qubes remain in English only.
Sometimes, when I open applications from a qube (Konsole, Firefox, etc.), they don’t appear on the screen. Everything seems to be running, but the windows aren’t shown. Switching to Xfce, opening the apps there, and then switching back to KDE helps temporarily. It’s a floating issue.
Tray icons look terrible and unusable. The Wi-Fi icon is just a white square, Clipboard and Disk Usage icons are black (invisible on the dark panel), and other icons, like Whonix, look ugly. This is a minor issue though.
These are the issues I’ve encountered in just the first couple of hours.
Are there any active KDE users here?
I wonder whether KDE is ready to use in Qubes and there are people who use it regularly.
If such people are here, could you give me some hints on how to fix these problems, especially the keyboard layout switching?
Hi! Yes, I think there are many of us, because it’s rich in functionality, and it used to be the default in Qubes OS (and I’ve not seen a good argument why it shouldn’t be the default again). There’s this long thread all about KDE where all bugs you mentioned are discussed:
You can find mentions elsewhere in the forum too, but perhaps the thread is easier to search through.
In that thread I posted something related to the first and the third bug you mention: KDE - changing the way you use Qubes - #204 by StanleyQubrick
Later I found that neither Fcitx5 nor ibus work as well and smooth as I thought they would (limitations on when global hotkeys can be detected) so I configured a different thing instead. So for the 3 bugs you mentioned:
Keyboard layout switching: Depending on which features you prefer, there are a few ways to solve this (there are tradeoffs). I’d recommend one method where you can configure a different global hotkey for each keyboard layout - it works reliably and without looking for visual feedback from a tray icon or whatever. You don’t get a tray icon at all (or maybe someone can suggest a separate program just for that) but you just press the desired keyboard combination at any time and you can just start typing in the corresponding layout. In this method the layout is controlled by setxkbmap (which is already installed in templates) and in the template you install the package sxhkd for configuring hotkeys (you can do without it, but you get very limited options for hotkeys from just setxkbmap) and you create and put one config file (~/.config/sxhkd/sxhkdrc) in each qube or template where you would like to be able to switch layouts. If you choose this method, let me know if you need instructions for this.
The other method that I think would still be preferred by some is Fcitx5, as I mentioned in that thread. It has a working system tray icon and other features, but it doesn’t behave well if you want to change layouts quickly, independently of the user interface of various software. You need to click a text field (and only text fields! No drop-down menus, for example ) where you’re going to type before you can switch layouts, which, as far as I understand it, is a case of bad design (affecting much of Linux, not only Qubes) leading to more and more idiotic things. But if that quirk and chore doesn’t bother you, I guess it’s fine.
I think you may have bumped into the issue of the KDE Plasma+Wayland session being the new default in KDE, while being completely unsupported and broken on Qubes OS (not opening some windows). When logging in, you need to make sure you select Plasma/X11 session, rather than Plasma/Wayland or XFCE, and then this choice gets remembered. Also, logging out of your KDE Plasma session and logging back in unfortunately leads to multiple issues, so I’d reboot Qubes OS before logging into KDE Plasma/X11 again.
The network tray icon and any other system tray icons based on Gtk3 are known to appear as white squares on KDE on Qubes OS. If you end up with more than one or two such icons after you install software maybe my suggestions and script from the other thread can help somewhat.
For the qui tool icons that are black on transparent background I can suggest changing the theme so that the system tray is not that dark, or searching for general KDE Plasma solutions or workarounds for this situation of black icons in dark themes.
I can vouch for this. Many KDE users who (generally) see the issues
you’ve raised as trivial compared to the functionality that KDE brings.
But every one has their own levels of what they will put up with. I dont
recognise your issue 2 and I suspect the X11/Wayland choice might
resolve it.
There’s a FAQ on keyboard switching which you might find worth
reading. It’s not a KDE issue.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
IIUIC switch from KDE to XFCE was done because KDE moved to Wayland and Wayland support in QubesOS is still not much ready (there is XWayland, but that’s not the same).
No, the switch was done because Joanna thought that KDE was bloated and
ugly. (Never was “the eye of the beholder” more apposite.)
Wayland was not an issue.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
I don’t think that such a comparison is relevant. And if you mean “dealing with KDE’s issues on Qubes OS will still probably take less of your time than alternatives” that would not necessarily be a sign of good software Especially when currently users would need to know to search or ask beforehand to get an idea of what they would be getting into, which is an issue in itself. The way I would look at it is that each unaddressed issue leads to some loss of potential users (not to mention time, etc.)
Anyway, while the serious issue with the keyboard layout seems to be actually not rooted in KDE packages, I think that the issue of the Wayland session being the default should also be taken seriously. It’s just a bad initial experience to be greeted with a non-functioning system, and it’s confusing, too. I bumped into it when I did an in-place upgrade from Qubes OS 4.1 to 4.2 (with many other issues along the way) and at first I didn’t notice, and I was surprised not that there was a new option in the drop-down menu, but that, at the same time, the new option would be the default one, even more so despite the fact that normally the last selection is remembered. After I had logged in I couldn’t tell exactly why (if I recall correctly) no qube window would open, while dom0 applications would open, and I had no obvious indication that this was Wayland and not X11.
So I’m sure that, if the situation is still the same, changing the default option (or alternatively, removing the Wayland option) would save in aggregate many user-hours of confusion, uninstalling, looking up, etc.
The network tray icon and any other system tray icons based on Gtk3 are known to appear as white squares on KDE on Qubes OS.
A simple solution for solving this issue: install on dom0 “stalonetray”, add a stalonetray.desktop in the dom0 .config/autostart, configure it as you wish in the .stalonetrayrc.
You obtain an additional “stand alone” bar only for tray, that will get all the tray icons (they then do not go anymore into the plasma bar).
The only issue I have: 1) sometime, when some sys-usb vm restarts, the blueman tray icon disappears. 2) I lost the proton VPN tray app after a recent upgrade (about one month ago, I think); I could not solve this one.
Sorry for the delay. Here are the instructions. As a reminder: the concept here is that you get distinct shortcuts for each keyboard layout and no indicator icon, rather than a single toggle shortcut plus an indicator icon for visual feedback. Importantly, these shortcuts can work reliably, and it doesn’t hurt to press the right one again at any time (as long as the intended qube’s window is in focus) to make sure you have the right layout on. So I think it’s a good way to be switching layouts.
Install the sxhkd package in the desired templates the way you normally install software in Qubes OS.
In each existing qube where you want to enable keyboard shortcuts for switching languages you need to add two files (recreate the directory structure). To configure keyboard shortcuts and specify keyboard layouts you need /home/user/.config/sxhkd/sxhkdrc. Check sxhkd’s man page for configuration syntax. My example file below is a bit complicated so the shortcuts wouldn’t interfere with other common shortcuts involving the same keys, and to make them work regardless of key order. If the documentation is not enough for some complications and corner cases like this, use search/chat bots/experimentation. Change the language es to whatever language and keyboard layout you need (check setxkbmap’s documentation for that, if needed) and make sure you keep the ,us part at the end if the letters are much different, otherwise common shortcuts involving letter keys will break.
Example sxhkdrc file (mind the whitespaces):
alt + ~Shift_L
setxkbmap -layout "es,us"
shift + ~Alt_L
setxkbmap -layout "es,us"
alt + ~Control_L
setxkbmap -layout "us"
control + ~Alt_L
setxkbmap -layout "us"
To automatically start listening for the hotkey each time the qube boots you can create /home/user/.config/autostart/sxhkd.desktop:
[Desktop Entry]
Name=sxhkd
Comment=Simple X hotkey daemon
Exec=/usr/bin/sxhkd
Terminal=false
Type=Application
When you configure one qube and make sure it works correctly with no bugs you can copy the files to the other qubes. You can also make it so all new qubes you create based on a certain template inherit these files in the correct directories, by placing the files at /etc/skel/.config/sxhkd/sxhkdrc and /etc/skel/.config/autostart/sxhkd.desktop in the template.
There are different ways to implement something like this without sxhkd and instead using KDE’s own global shortcuts (which is less flexible than sxhkd in the keyboard combinations it accepts) + bash scripts in dom0. The chores needed per qube can be removed.
I was like you, but now, I think xfce has hit the end of the line, it was hard on my eyes and too hard to scale as well as seems to be have been mostly abandoned as can be seen by how nobody seems to have worked on a HiDPi solution yet.
I would also add in a security perspective that KDE has better (input) isolation and permission controls. I know and agree with the argument of xfce being more minimal, smaller code-base, and more established, but balance that with KDE having much more people working on it and are faster to patch known vulnerabilities .
First, only Alt+Shift, Alt+Ctrl, or Ctrl+Shift combinations work. If I try to assign normal keyboard keys, they don’t work. For example, if I try to assign Alt+Shift+2 to a layout, it doesn’t work. I suppose I would need to use a specific key code instead of “2”?
Secondly, after assigning these keys, Ctrl functionality in text editors and office apps no longer works. I can’t use Ctrl+A or Ctrl+Z, for example. Is there a workaround for this?
I forgot to mention that first you need to at least disable any other listeners for the same key combination. Unless you want to be able to switch layouts for dom0 itself, you can disable KDE’s layout switcher from System Settings → Input devices → Keyboard → Layouts → delete the keyboard shortcuts you want to use in sxhkd instead and uncheck Configure layouts. If you have Fcitx5 or IBus installed, remove them completely. Speaking of them, aren’t they good enough for you, and easier to configure (they have GUI)?
As for sxhkd, you may want to also check for relevant info in a wiki page, Example Bindings, forum thread. Looking at the key combination you wrote, “Alt+Shift+2”, maybe the problem is that the syntax in the sxhkdrc config file is case sensitive, and you have to type alt+shift+2 in there.
These typical Linux config files and CLI stuff are like this - you’re expected to read documentation for every little thing, they’re all different, unintuitive (unless you have exactly the right mental condition, I suppose, or you wrote the thing yourself), and you end up needing to experiment anyway. IMO LLMs are the only hope of redeeming them. Finally a synthetic nerd that can provide them the attention they require.
) where you’re going to type before you can switch layouts, which, as far as I understand it, is a case of bad design (affecting much of Linux, not only Qubes) leading to more and more idiotic things. But if that quirk and chore doesn’t bother you, I guess it’s fine.
Especially when currently users would need to know to search or ask beforehand to get an idea of what they would be getting into, which is an issue in itself. The way I would look at it is that each unaddressed issue leads to some loss of potential users (not to mention time, etc.)