151–160 of 248 posts
KeepassXC (a must-have application and dealbreaker) is still broken on Wayland. The recommended "solution" is to edit the .desktop file to resemble the following: QT_QPA_PLATFORM=wayland ECORE_EVAS_ENGINE=wayland_egl ELM_ENGINE=wayland_egl SDL_VIDEODRIVER=wayland _JAVA_AWT_WM_NONREPARENTING=1 keepassxc https://github.com/keepassxreboot/keepassxc/issues/2973
Earlier quoted context omitted.
Wayland+sway switch from x11+i3 is so simple and works so well. Only minor annoying thing not working for me are right-click context menus on some applets like Blueman and Steam.
With a tiny tiny caveat of wanting to run Nvidia drivers instead of nouveau.
Earlier quoted context omitted.
Wayland was started primarily by those who were maintaining X11. There is almost nobody who is both capable of working on X11 and wants to work on it. The redesign also reflects their priorities. The best analogy I can come up with is imagine a small group of people maintaining an old car frame and mechanical workings. They work hard to keep the engine running, but it's in a chassis with leaf springs and direct steer…
>Wayland was started primarily by those who were maintaining X11. There is almost nobody who is both capable of working on X11 and wants to work on it. Isn't wayland just soem protocol? so did the ex X11 devs wrote soem specifications and then soem went to GNOME I think the issue is that there is no wayland library that a DE can use so everyone is forced to implement it as part of the DE , so the end result is a lot…
> The wayland protocol is essentially only about input handling and buffer management
So sending input to clients and managing the buffers needed is what wayland implements. Everything else is either done in the clients (e.g. rendering) or the compositor (pretty much everything else).
Note that this is a subset of what X11 did (though rendering had pretty much already moved to the client for modern applications). X11, of course, handled input, and it also provided an IPC mechanism (which is how clients e.g. communicated things to the WM). Wayland, at its core, is just those two things.
I live in a cave and am not a system programmer -- what's so wrong with X11 so people need to replace it with something else instead of improving it? Or, what's so wrong with anything so people need to replace it with something else instead of improving it? Let's say I'm an old man favoring improving existing stuffs instead of starting from scratch. I like debugging and wish to work as a sys programmer specialized in…
> I live in a cave and am not a system programmer -- what's so wrong with X11 so people need to replace it with something else instead of improving it? Tech debt. The X11 dev have thrown the towel and have prefered working on something they deemed more maintainable.
This is an interesting move, and I wonder what that means for accessibility in Plasma. Wayland simply isn't designed with accessibility in mind, so each compositor ends up having to implement their own non-standard APIs. I know virtual keyboards are lacking for example.
Earlier quoted context omitted.
> what's so wrong with X11 so people need to replace it 1. Security - Any program using X11 can read keystrokes, passwords, or the contents of any other window. Fixing this would break all existing X11 applications. 2. Performance - X11's client-server model doesn't work with hardware accelerated graphics, requiring hacks to get around. X11 is basically stuck with this legacy. The ground-up re-design of X11 to fix th…
I 100% agree with the performance improvement goals, but I think the security claims are overblown, and overly cautious. I honestly don't understand the point of trying to implement the security boundary in the display manager. It solves one class of security issues, while breaking a lot of accessibility and automation. The display manager just shouldn't be enforcing rigid per processes security controls, that's bett…
This is a real shame. I'm using X11 still because Discord doesn't work properly with Wayland, and the alternative (Vesktop) doesn't support keybinds when the window isn't focused. Since my distro (Arch) doesn't support holding back packages, I guess I'll have to switch distros entirely so that my Discord setup stays working. :/
The only difference between Arch and any other regular distro is simply that in Arch there are no major upgrade versions, so any breaking changes you have to perform them manually. Period.
In the rest, they do it for you. But they update key components as well and/or stop getting updated at some point (same as not updating Arch).
For example, I am a happy Fedora user, but I don't get why they don't upgrade the Plasma or Gnome version in the same release but they do upgrade the kernel, when the kernel update may bring more breaking changes...
Earlier quoted context omitted.
I find your comment a bit funny on multiple levels. "Linux" does not force anything on you right? It's the community that has by and large decided to move to maintaining other solutions. If you still want to use fvwm you can still run it on arch with x11 until x11 is not maintained and the kernel breaks it somehow
"Linux" is mostly controlled by a few corporations and their interests. It's been a loooooooooong time since it was a grass roots movement. I don't know about you, but corporate dictates always leave a bad taste in my mouth.
The Linux software environment is more broadly controlled by corporations, but that goes for every single mainstream operating system.
This is an interesting move, and I wonder what that means for accessibility in Plasma. Wayland simply isn't designed with accessibility in mind, so each compositor ends up having to implement their own non-standard APIs. I know virtual keyboards are lacking for example.
Wayland is missing one thing still for me. Perhaps someone can tell me there is a way to do this: 1. ssh into a machine with a running session 2. start (something) that lets me remotely connect to it Right now I have two working solutions for X11 (x11vnc, freerdp-shadow) but zero for Wayland. I think this is intentional because the venn diagram of remote-access-tools and malware has a large intersection, but it's ver…
For RDP, you've got KRDP and gnome-remote-desktop. That "with a running session" bit greatly helps here. While GDM allows you to have remote login and headless sessions [1], with SDDM you're locked out for the moment. There's plans to turn SDDM into a KDE-powered, more featured plasma-login-manager with KRDP integration, but no concrete development yet [2]. [1]: https://gitlab.gnome.org/GNOME/gnome-remote-desktop [2]…