Live data from Hacker News

Preparing for KDE Plasma's Last X11-Supported Release

blog.davidedmundson.co.uk

191–200 of 392 posts

Re: Preparing for KDE Plasma's Last X11-Supported Release

#191
post #46

I read this yesterday wanted to raise awareness for it - https://nocoffei.com/?p=451 It describes the regression in accessibility software for Linux from x11 to Wayland. Unfortunately, judging by the pace of protocols being accepted, I think we're years out from having a solution. The most notable thing not working is Talon, which is a voice input system that lets you insert speech to text, manipulate windows, call s…

It’ll be a better place when Wayland (and by extension Gnome/KDE) stops becoming a cargo cult hell bent on destroying X11/Xlibre.

Re: Preparing for KDE Plasma's Last X11-Supported Release

#192
post #76

Does anyone know if there is any progress on window shading on Wayland? I miss it like crazy.

Same. Given that no Wayland compositors implement it, or anything like it, and from some of my surface level reading about how compositors work, I get the impression Wayland is particularly ill-suited for this feature. I don't understand enough to understand exactly why, or why a new Wayland "protocol" would be required, though that seemed to be the answer. I hate not having this feature, it makes me feel trapped in an entire desktop paradigm I don't desire to be locked into.

Re: Preparing for KDE Plasma's Last X11-Supported Release

#193
post #8

What's sad is that after many years Wayland still lacks several things/features that X11 has/allows. Some of them are intentionally not implemented because of security paranoia. For example, Chrome "picture in picture" window doesn't stay on top when I click somewhere else since Wayland doesn't allow windows to stay on top. If I had a lot of time I could list how Wayland breaks many applications. Not saying that X11…

Isn't it also impossible to spawn a window in the last place it was open (or any arbitrary point) because you're not allowed to know or change where your window is by design? Nonsense like that makes me dread having to eventually use it.

They "fixed" that by implementing multiple conflicting and optional experimental extensions that may or may not randomly be supported by your particular WM/DE, and may or may not be DE-specific protocols in the first place.

https://wayland.app/protocols/

Re: Preparing for KDE Plasma's Last X11-Supported Release

#194
post #37

Earlier quoted context omitted.

If you use KDE, you can work around this because of the powerful feature set the window manager has for setting custom window behavior. 1. Right click the PIP window and then click "More Actions-> Special Window Settings". 2. On the window that pops up, click "Add Property", and add "Window title". Change the drop-down from "Unimportant" to "Exact match" (this works on Firefox because the window title is always "Pict…

Not too bad? A hidden procedure with ten clicks, which the user has to repeat for each web browser. And it may break at any time if the browser changes some details. Or if KDE changes. And it's specific to KDE, with no alternatives in most Wayland WMs. All that for _one_ feature which works out-of-the-box with Xorg, and which Wayland removed for security reasons. From what I've seen, sharing the screen is another com…

Note there is also a far simpler one: You can right-click the window on the taskbar and click Keep Above. This works for any window.

Re: Preparing for KDE Plasma's Last X11-Supported Release

#195

Plasma/Wayland Known Significant Issues[1] No ability to save and restore positions of native Wayland windows Real-fake-session-restored apps don't remember which virtual desktop their windows were on No full-screen aspect ratio correction "Spare Layouts" feature not implemented "Per-application Keyboard Layout" does not work No way to change the gamma or manually adjust the colors without generating or finding an ap…

Also, I still haven't found a clipboard manager that works normally on Wayland.

And I rarely get it to recognize all my monitors first try. And it crashes semi-regularly.

Not sure how much is inherent to Wayland vs Gnome, but life is way better since I upgraded to Xlibre & Cinnamon.

Re: Preparing for KDE Plasma's Last X11-Supported Release

#196
post #63
post #3

How can I embed my mpv window in other application now?

qimgv uses libmpv for video playback support for example. I'm guessing that's not what you mean, but I'm struggling to think of how one might "embed" one application inside of another on xorg.

On Windows it's trivial, just reparent[1] the main window of the subprocess to a window in your process. Technically you should clear a couple of window flags as well, but that's trivial too.

[1]: https://learn.microsoft.com/en-us/windows/win32/api/winuser/...

Re: Preparing for KDE Plasma's Last X11-Supported Release

#197

Earlier quoted context omitted.

I actually prefer macOS's PiP handling compared to other operating systems. In that it's a blessed concept that only goes to one corner of the screen and can be shunted out of the way easily.

Now imagine if that was designed properly, and you could just do that to any window, regardless of what the program thinks it should look like.

I use pinned (always above + on all workspace/desktop) quite often.

And to make it ergonomic I scripted kwin and set some shortcuts.

So yes, you can have any window PiP the way you like. But it requires you to do a long sequence of actions. Versus a single click for very specific PiP behavior.

Consider a window in a web browser tab. You could click the PiP button, which will pop out a tiny window, most likely already in a corner of the screen. This window is a mini video player. Your original browser tab stays untoucher, still at the same place in your web browser tab list, the rest of the tab still readable and scrollable etc etc.

Or, you could clone the tab. Move it to its own window. Locate the video. Put it in full screen. Un-fullscreen the window. Click on the pin button. Resize the window to the corner.

Same result, but not the same effort.

Re: Preparing for KDE Plasma's Last X11-Supported Release

#198

Earlier quoted context omitted.

I have a virtual pinball cab with two (and soon) three displays. Wayland really makes life difficult here because the software needs to always put the playfield on one display, the backglass on another, and the "dot matrix display" window on a third. That's a big no-no with Wayland. Fortunately KDE has window rules as a workaround. Sway and Hyprland allow similar rules. Mutter on Gnome has no equivalent. I'm guessing…

Ironically, the use case you described is exactly the sort of thing Wayland really excels at - if you're willing to write your own compositor. There's plenty of embedded devices that ship with an extremely simple Wayland compositor that does exactly this. It opens up one app, accepts as many windows from that app as it has displays, and renders one window per display. That's that. There's no super-secret desktop that…

This is great. But this doesn't cover the general expectation of a desktop application.

I want application to know the screens, send windows to know positions etc etc. And this is now compositor specific. So some applications will know how to talk to the kde compositor to share the screen, or place a window at a specific position (very useful for so many things).

Re: Preparing for KDE Plasma's Last X11-Supported Release

#199
post #88

Earlier quoted context omitted.

I also think it's unfortunate that Talon is closed source. You see this even in the support practices adopted, where all support is routed through a slack chatroom which doesn't let you view history older than I want to say a few months but might be wrong on the length of time. The author seems to want to force all support requests to go directly through him, presumably because it increases his income if he can creat…

Hi, I'm the developer of Talon. It's possible to do the simple compositor specific hacks from Talon's scripting system to give yourself partial Wayland support at roughly the quality I'd be able to provide myself, and I know of a couple efforts to do this. The tentative plan for "dropping support for X11" is just to do one more public Linux X11 release, stop there, leave it available to download, and make it very cle…

This seems like it basically confirms ggp's complaints: You're not interested in addressing customers' needs, or giving them ways to address their needs themselves, and are instead taking a "if this doesn't meet my standards you're not allowed to do it" standpoint.

If slack interactions are so unpleasant, why do you direct all support through it?

Is there no way you could say "yes this is a hack, but we'll live with it for now until an actually good solution is available"? Maybe it could be added in such a way that it's easy to remove later (abstraction, encapsulation)?

Re: Preparing for KDE Plasma's Last X11-Supported Release

#200

Earlier quoted context omitted.

For the records, Debian 13 Gnome with Wayland works as well as with X11. The only reason I'm still using X11 is that backlight control doesn't work anymore with my old laptop (it did with Debian 11) and X11 can work around it with gamma correction and Wayland can not.

KWin can do dimming in hardware or by messing with the colors - not sure how.

Messing with colors looks like gamma correction and dimming in hardware is the backlight control that does not work anymore on my laptop.

I don't remember why gamma correction didn't work for me Wayland but I'll give it another try next year, maybe it got fixed by then. X11 is working perfectly well and it always did for me.

Post reply on HN