Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Preparing for KDE Plasma's Last X11-Supported Release

blog.davidedmundson.co.uk

Post reply on HN
Print view View original

241–250 of 392 posts

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

#241

Post by tmtvl »

HiPhish wrote: post #130

I really miss the ability to swap out KWin for a tiling window manager. I'm currently using Krohnkite and it's OK, much better than nothing, but after having used a real tiling window manager the difference is just too jarring. I physically need a desktop which is usable as much as possible both with the mouse and with the keyboard so I have to switch as rarely between the two as possible. Plasma on X11 with a tiling…

Have you tried LXQt? It made things easy for me when Plasma 6 broke a KWin script I was using to improve the multihead experience.

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

#242

Post by account42 »

porridgeraisin wrote: post #105
thesuitonym wrote: post #80

Earlier quoted context omitted.

Look, I'm not a Wayland booster, I still prefer X11 most of the time, but this is really the way it should work. Applications should not be allowed to dictate how windows appear. That is the job of the window manager. Chrome's PIP is a stupid workaround for Windows and Mac because they do not have robust window management.

This is the issue with imposing semantics of the programming model on the behaviour. User behaviour is the only _real_ thing, it happens. Everything else is in your head. If people in the real world use PiP, then it should happen. The programming model has to bend and change to support it. It simply does not matter if the window manager does something or the window does something. Sure, there is always the security a…

Permission prompts still only allow things that have already been thought of so we will see less innovation in the future. I don't think this kind of security model is needed at all for an open source desktop where we can enforce directly that programs respect the user instead.

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

#243

Post by account42 »

gmueckl wrote: post #171
porridgeraisin wrote: post #121

Earlier quoted context omitted.

That's exactly what I said... and also not how wayland works. I cannot comprehend the way wayland folks think... quote from the xdg-pip discussion: > To not make PiP windows effectively "always on top" and "on every workspace" dialogs - a terrible and sadly by applications used concept on X11 - PiP windows must be input-only, i.e. not receive keyboard, pointer and touch input Like what the heck even? That is how pip…

I also don't get it with the wayland people. It feels like they want to revert everything to a UX design that was getting old in the 90s.

They want to turn everything into an appliance.

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

#244

Post by account42 »

sho_hn wrote: post #194
idoubtit wrote: post #77

Earlier quoted context omitted.

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.

But then you'll have to do it every time.

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

#245

Post by account42 »

gf000 wrote: post #219
idoubtit wrote: post #77

Earlier quoted context omitted.

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…

> I have faith in Debian for filtering out rogue applications Sorry but all I can say to that is: lol As for security, it's easy/possible to cut holes into a solid wall. But if your whole system is swiss cheese, you can't plug all of them in. Wayland is a solid wall where protocols are the means to cut new holes. Sure, protocol development is slow (at least their acceptance), but this is the proper way to do it. And…

Debian applications are not sandboxed so gimping the window system gains you exactly nothing. And yes, we can expect Debian to filter rogue applications.

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

#246

Post by mschuster91 »

timhh wrote: post #230
The_President wrote: post #116

Earlier quoted context omitted.

The Bluetooth integration needs work - missing features such as "never connect automatically." Default lock screen experience still has a needless delay of 5 seconds when entering a wrong (even blank wrong) password, even on the first attempt. +1 on the gamma controls

> Default lock screen experience still has a needless delay of 5 seconds when entering a wrong (even blank wrong) password, even on the first attempt. I suspect that is not KDE's fault (or Wayland's) - it's probably PAM, which by default has a 2 second delay (+/- 50%). That default is extremely difficult to change, but you can configure it. See my instructions here: https://github.com/linux-pam/linux-pam/issues/778#i…

Good lord that thread is a dumpster fire. Thanks for finding out wtf is causing this, it has annoyed me for two darn decades, but never enough to go as deep into finding the cause…

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

#247

Post by account42 »

teo_zero wrote: post #209
senfiaj wrote: 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…

> doesn't allow windows to stay on top. Are you sure that windows that, without your consent, are allowed to stay on top and grab your input are a good idea? And spawned by Chrome? As if we hadn't already enough ad-ware, click-harvesters, and spoofed dialogs popping up everywhere! I know there is a couple of legitimate uses for this, but the ways it can be abused are vastly more. I think the sensitive default should…

Are you aware that if software misuses the capabilities its given by the system you can choose to stop using that software?

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

#248

Post by account42 »

babypuncher wrote: post #92
senfiaj wrote: 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…

> 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. Wayland doesn't allow apps to force themselves to be always on top. I would argue that it is up to the window manager to provide this functionality at the discretion of the user. Kwin does this.

I would argue that software that I choose to install already has my discretion and should not be limited by the windowing system in what it can do.

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

#249

Post by account42 »

chlorion wrote: post #184
craftkiller wrote: post #124

Earlier quoted context omitted.

What did you learn when you checked the logs to see what was wrong?

Probably didn't even bother to diagnose the issue. It's hard to tell if it was even wayland related without logs and some digging. But lets just blindly blame wayland cause new thing bad!

Blame on Wayland is absolutely justified here. If you force changes onto others its up to you to make sure you're not breaking things.

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

#250

Post by account42 »

d3Xt3r wrote: post #122
httpsterio wrote: post #111

Earlier quoted context omitted.

my experience us sadly the opposite. when I'm recording gameplay with OBS with x11 and xfce I have roughly a 7-9ms frame render time and with Wayland and any desktop env it creeps up above 16ms, which means I can't get a solid 60fps. in all other cases other than gaming and recording, Wayland has been a delight.

If your aim is to only record gameplay (and not stream), then there are far better Wayland-native tools like wl-screenrec[1] for wlroots-based compositors and gpu-screen-recorder[2] for others. The latter even supports live streaming, so could be used as a lightweight alternative to OBS. [1] https://github.com/russelltg/wl-screenrec [2] https://git.dec05eba.com/gpu-screen-recorder/about/

With X11 you don't have to care about what wm/compositor you're using to choose a screen recorder.
Post reply on HN