Live data from Hacker News

Preparing for KDE Plasma's Last X11-Supported Release

blog.davidedmundson.co.uk

321–330 of 392 posts

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

#321
post #149
post #96

Earlier quoted context omitted.

"Alternatively it might make sense to build some type of bespoke solution on top of a specific wayland stack, like re implementing what you get of talon in a kde plugin or via sway IPC. This seems viable to me but an incredible amount of work." I think that is the only way forward. There is no "Linux desktop". There is KDE, Gnome etc. and if you want to do "system utilities" you have to target one of those.

The point though is that there used to be a «Linux desktop» you could target before the Wayland transition. Fragmentation of an already small market segment is unfortunate.

There was not really for system utilities. Apps, sure, but not system utilities.

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

#322
post #210
post #96

Earlier quoted context omitted.

"Alternatively it might make sense to build some type of bespoke solution on top of a specific wayland stack, like re implementing what you get of talon in a kde plugin or via sway IPC. This seems viable to me but an incredible amount of work." I think that is the only way forward. There is no "Linux desktop". There is KDE, Gnome etc. and if you want to do "system utilities" you have to target one of those.

No, that's a terrible idea. The right thing to do is design a Wayland protocol that gives you the access you need, get it accepted into wayland-protocols, and wait for all the compositors to implement it. Yes, that's a slow, annoying process, but doing something bespoke means either you do the same work over and over for every compositor, or you only support one or two compositors. Neither of those is a good result.

It is way faster and better to implement what you want/need in the DE. Later, it it makes sense, you can standardize it.

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

#323
post #100

Earlier quoted context omitted.

More and more Free SW will depend on Systemd (like next gen flatpak). Make something better or adapt.

No, I will use software that respects me instead of software that makes demands of me.

Software can not respect you, it is not sentient.

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

#324
post #320

Earlier quoted context omitted.

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…

Hi Lunixbochs, thank you for the comment. One of my take aways from the article was that you were considering removing the ability for Talon to work on x11 in the future. I appreciate the correction. I understand that you're dealing with a lot of unpleasant support requests (especially because people who have to use Talon are probably frustrated at having lost the ability to use their machine normally). I am sorry if…

Thank you.

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

#325

Earlier quoted context omitted.

You can't do anything about a compromised app or JS from a random website. I always find it weird when people attack Wayland's security model, more isolation is obviously a great idea, as demonstrated by supply chain attacks in the recent decade. It's that Wayland's design, implementation, their attitude, and everything else about it is terrible. It could have been implemented without compromising on features or conv…

Turn off the web browser feature that allows JS in an advertisement in a background tab to globally grab your input.

Sure, browsers had three decades of adversarial testing to evolve into sandboxes, but what are you going to do in case of something like the xz backdoor in a desktop application? It's no longer a hypothetical in 2020s.

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

#326
post #149

Earlier quoted context omitted.

The point though is that there used to be a «Linux desktop» you could target before the Wayland transition. Fragmentation of an already small market segment is unfortunate.

It's KDE now. GNOME is the penguin that went to the mountains while KDE largely tries to be compatible with things that aren't KDE.

Sure. I use KDE myself. I actually like the Gnome default UI/UX more, but I'm really not fond of their "our way or the highway" approach when it comes to customization and interoperability. KDE feels more in line with the true FOSS "spirit", and after a bit of customization, fits my needs better than Gnome.

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

#327

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

Well, seeing how systems are brute-forced and how much speed you can achieve today, these delays are more and more welcome on my end.

Authentication systems had lock out periods or increasing delays since decades. 1 attempt per 5 seconds and 12 attempts per minute would be equivalent for brute force. And 12 attempts per minute would be a very loose lock out policy.

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

#328
post #321
post #149

Earlier quoted context omitted.

The point though is that there used to be a «Linux desktop» you could target before the Wayland transition. Fragmentation of an already small market segment is unfortunate.

There was not really for system utilities. Apps, sure, but not system utilities.

What do you refer to as system utilities? All the stuff now subsumed by SystemD?

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

#329

Slight tangent but has anyone moved from AwesomeWM to a Wayland-based tiling WM? Interested to hear what people chose. I tried Sway for a bit and while it's not bad by any means it's a bit too unlike what I'm used to. SomeWM is an attempt at "porting" AwesomeWM to Wayland and looks very promising but not quite there yet (I couldn't get Vicious widgets working and not sure if supporting them is even a goal). I'm still…

> not sure if supporting them is even a goal

Technically, it is a goal, though perhaps an optimistic one.

I won't support vicious widgets in the 2.x releases, but I should definitely add support for it in the release/1.4 branch that follows AwesomeWM master/4.4. Not that I think vicious widgets are the best, but technically if it runs on AwesomeWM, I should support it in 1.4.

I created an issue (https://github.com/trip-zip/somewm/issues/599), even if you decide not to use SomeWM. Thanks for trying it out.

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

#330
post #254

Earlier quoted context omitted.

I settled on river¹ after a couple of decades with awesomewm. Tiling and tagging work in a way you'd expect coming from awesomewm, but nothing else does. I made my mind up because having to use workspaces and manual tiling is a far harder sell than implementing the functionality I want on top of a decent base. If anything it reminds me more of the experience with using awesome v2(before lua); you generate a config fi…

I had seen river but for some reason didn't look too much into it. I think it's because at first glance it looks like a protocol that you can build a WM on, rather than a WM itself, but I guess it's probably easy to build your own tooling over it (a lot easier than "building your own WM" in the traditional sense)? I'll give it a look - thanks!

If you want an out of the box test then playing with river-classic¹ is probably a good place to start. It gives a feel for where you can go, without having to put too much effort in.

For example, it has pluggable layouts where instead of pulling in a lua module(such as awful.layout) in awesome you'll run an external process which handles events. You can even run multiple managers and switch between them with bindings, or write a custom one to scratch that itch. If you're happy with just awful's .suit.tile.right and .suit.max then basically any backend will do.

This is why it feels like a reasonable path off awesomewm to me. I always considered awesomewm to be the WMConstructionKit, and while river changes how you interact there is still a nice route to extensibility. The newer direction even more so than the -classic offshoot.

¹ https://codeberg.org/river/river-classic

Post reply on HN