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.
Preparing for KDE Plasma's Last X11-Supported Release
321–330 of 392 posts
Re: Preparing for KDE Plasma's Last X11-Supported Release
#322Earlier 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.
Re: Preparing for KDE Plasma's Last X11-Supported Release
#323Re: Preparing for KDE Plasma's Last X11-Supported Release
#324Earlier 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…
Re: Preparing for KDE Plasma's Last X11-Supported Release
#325Earlier 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.
Re: Preparing for KDE Plasma's Last X11-Supported Release
#326Earlier 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.
Re: Preparing for KDE Plasma's Last X11-Supported Release
#327Earlier 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.
Re: Preparing for KDE Plasma's Last X11-Supported Release
#328Earlier 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.
Re: Preparing for KDE Plasma's Last X11-Supported Release
#329Slight 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…
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
#330Earlier 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!
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.