May I ask, which Linux distro do you use? I’m thinking also to move away from Cinnamon and Mint, but I’m not sure about distro …
I’ve tried LXQt. It came up with a taskbar(?) that didn’t display all icons/buttons (but when I clicked there, it did react, e.g. to show a ‘start’ menu). So I logged out and logged back into KDE - which LXQt destroyed (e.g. the KDE ‘start’ menu button had the Gnome ‘footprint’ icon, fonts were all over the place). I tried undoing those, but ended up having to remove my KDE config directories and files to get it back into shape.
This was under Ubuntu. Could be a packaging issue.
1 Like
It’s really not. Every desktop likes to write their own configs to ~/.config/gtk3.0, same for the rest of gtk, it’s a big mess.
In my experience these less maintained projects are the worst in that regard, they won’t respect anything and will override settings at will. AFAIK KDE has their own config directories, so it’s hard to see how LXQt managed to override KDE’s start menu icon, but who knows at this point.
I get that DE’s need to override configs to make things feel ‘native’, whatever that is it’s an impossible task in linux, but it is done horribly and I wonder how we got into this predicament.
Maybe with better cooperation Gnome wouldn’t have gone nuclear with libadwaita and things would’ve progressed differently.
1 Like
Never tried it but thought the general recommendation is using separate users when mixing DEs.
Currently (or should that be Kurrently) Kubuntu 24.04 LTS.
However lately I’ve found the endless settings for the options for the preferences for the prefences in KDE somewhat bothersome, and you need to do bit of a fudge to get access to Google Calender etc on KDE.
2 Likes
I finally figured out how to get screen sharing on sway. I just needed a trivial ~/.config/xdg-desktop-portal/sway-portals.conf. Sway refuses to provide it, for reasons I cannot understand. So in the new year I will be trying out hyprland.
1 Like
that smells like a packaging error on your distro
our package has a /usr/share/xdg-desktop-portal/sway-portals.conf
cat /usr/share/xdg-desktop-portal/sway-portals.conf
[preferred]
default=wlr;gtk
I use the KDE spin of Fedora. At work I also used the Sway spin for several years, though unfortunately there were some Wayland-related issues (mostly with the responsiveness of specific applications when switching between workspaces) that ultimately made me switch back to KDE Plasma again.
It reads like “we want to keep the maintenance effort of Sway itself to a minimum and your distro can provide this just as well” to me. I think the Fedora Sway spin provides it because screen sharing worked fine for me in the past.
My distro has that file. But still it did not work. Providing the very same file in ~/.config fixed the issue. A mystery, but not one I am willing to debug further, it just works now.
Sounds like “you guys duplicate these trivial 2 lines in every single distro, just because we cannot be bothered”. Everyone else just provides it, eg hyprland.
This is such a bad attitude. Things should work out of the box. A distribution integrating a desktop enviroment/window manager into the distro should ensure that the file is provides so the experience between the different DE/WM is comparable.
In an ideal case the file would then be upstreamed so that behavior among distros is also the same. Requiring every user to RTFM to create that file (via copy paste) is just stupid.
With friendly greetings from a distro packager
do you have there referenced portal packages installed as well?
Yes, I went through the whole checklist. Everything was installed etc.
As much as I love tweaking Linux, I am just glad that it works now, even if I have no deep understanding of what the problem was. I am not touching those configs until I am done with Zoom meetings this year. 
there is actually one feature i really like about niri. it has a filter for window sharing, where you can block windows from never appearing in the list of offered windows. example config has e.g. keepassxc in it.
1 Like
The Linux experience summed up perfectly 
.
3 Likes
Back in the day, when booting took a lot longer, one could read stuff as it scrolled up the screen. That was educational. init was simpler, one could (even without computer-science education) get a hang of what was happening.
Today, a thousand lines shoot up the screen (if they are even displayed at all, many distros suppress it) so fast I don’t have a clue.
I think the point is that if there is a problem, they stop scrolling Otherwise, if the system actually boots up, you get them from the logs.
If you get a splash screen, in most cases Esc gets you back to the log firehose.
1 Like
As someone who’s been out of the game for a long time and trying to figure out the current state of Wayland, etc, does this mean that something like darktable won’t be color managed if you’re not using a DE like this? I know there’s other darktable users in this topic talking about tiling WMs and such so I want to be sure I’m understanding correctly…
I’m not really too picky about what I’m using. In the past I’ve used GNOME, Unity, Openbox, LXDE, XFCE, probably more that I’m forgetting. I’ve been messing with KDE in a VM, it seems perfectly fine.
it’s not even a Wayland/X.Org thing, the honest truth is outside of the Plasma/GNOME/COSMIC trio - most desktop environments have absolutely terrible colour handling due to simple lack of development, and Xfce can only get you so far without a Wayland protocol, for example, KDE & GNOME, with the exception of two compositors (Sway and Hyprland) are the only desktops on Linux/BSD with any sort of real HDR support
I like the DankLinux (https://danklinux.com/) experience with my niri
1 Like
For wayland, that is true, but for Xorg all you have to do i start xiccd and/or colord and you’ll get color management. I’ve been using i3 on my editing machine for years without issue and I just throw a systemd job for both of those and it works.