KDE Gets A 2022 Roadmap - Plasma Wayland To Shine, Updated Breeze Icons

[cl333r]

Just goes to show how many different settings that KDE has...because that setting doesn't exist where I was looking...and it should.

System Settings >Regional Settings>Formats[/IMG2]

Yeah IIRC at first I was also looking for it in System Settings and took me a while finding it in the applet's settings. IMO since a clock is a core feature of a desktop the configuration should be moved to or shared with System Settings.

[ⲣⲂaggins]

In many DE's you cannot really tell the difference between native Wayland and XWayland.
This is unfortunate so KDE introduced this feature where XWayland apps are slightly blurred. Now the users can always tell what protocol an app uses and behave accordingly.

You can use xeyes, in any DE.

[ⲣⲂaggins]

A major selling point of X was that the core never crashes, taking down your session. (Because it is so simple and hardly does anything nowadays anyway.)

Wayland, in its infinite wisdom, decided to make a complicated, opengl- and qt-using, javascript-running window manager the display server, so that its frequent and unavoidable crashes can bring down your session more often.

That's why I was surprised David Edmundsson's work (see video) wasn't even mentioned by Nate's roadmap. In my view it's the biggest remaining wayland roadblock.

[bug77]

Doing that would break the XDG settings dir spec. Maybe what we could do is prefix all our config files with "kde_". So you would have "kde_dolphinrc" and "kde_plasmashellrc" and so on. Then at least all the KDE stuff would be grouped when sorted by name.

What is "XDG settings dir spec"? Does it say "if you have some settings files and a dedicated settings dir, make sure the files are spread all over the said dir"?

[Frenzie]

A major selling point of X was that the core never crashes, taking down your session. (Because it is so simple and hardly does anything nowadays anyway.)

There's also the corollary that lack of xkill makes life a lot harder. (Although perhaps ironically, in X I don't need it… I've only felt the need in Wayland.)

[oiaohm]

A major selling point of X was that the core never crashes, taking down your session. (Because it is so simple and hardly does anything nowadays anyway.)

Sorry X11 x.org server still crashes on people taken down the complete session..

https://forums.opensuse.org/showthread.php/562992-Monitor-rotation-crashes-X-server-after-latest-update

Lots of strange and warped ways.

Wayland, in its infinite wisdom, decided to make a complicated, opengl- and qt-using, javascript-running window manager the display server, so that its frequent and unavoidable crashes can bring down your session more often.

More often is the correct statement. X11 x.org server due to years of development and basically being massively bipassed has come less likely to crash but its never got to crash free and most likely never well.

That's why I was surprised David Edmundsson's work (see video) wasn't even mentioned by Nate's roadmap. In my view it's the biggest remaining wayland roadblock.

The interesting point is lot of the changes being done by David Edmundsson was proposed back in the history of X11 protocol as well. Yes the developers of xpra used some of the features include in X11 protocol to handle reconnects. Of course the toolkit developers never did this work for the X11 protocol.

Really we do need to raise the bar here. Killing X11 sever be it Xwayland or bare metal in ideal world with all the same alterations done users application state would live to the other side. Reality is the odds of a truly crash free X11 server or Wayland compositor is basically zero. If application toolkits are design that crash is likely users don't have to be harmed no matter how frequent the crash problem is.

[oiaohm]

There's also the corollary that lack of xkill makes life a lot harder. (Although perhaps ironically, in X I don't need it… I've only felt the need in Wayland.)

You should avoid xkill there are issues in the X11 protocol where xkill can in fact kill the wrong process. This is were we need better task management and this is starting to come with cgroups around applications and the like.

[Frenzie]

You should avoid xkill there are issues in the X11 protocol where xkill can in fact kill the wrong process. This is were we need better task management and this is starting to come with cgroups around applications and the like.

It can? Interesting, thanks for the warning. But the chance of killing the wrong process is much higher still when I have to look for it myself in some kind of task/process manager, so it's pretty much a moot point.

[skeevy420]

Yeah IIRC at first I was also looking for it in System Settings and took me a while finding it in the applet's settings. IMO since a clock is a core feature of a desktop the configuration should be moved to or shared with System Settings.

I tend to forget that some of the applets and widgets have their own settings in addition to the KDE System Settings. I was so bent up on trying to configure the system time via system settings that I didn't even think to consider the digital clock's widget might have a 12/24 option in its settings.

When people talk about KDE having too many options, I think they also mean issues like this where you have multiple places to configure an option so you go the wrong place or common sense makes you think one thing while the option is somewhere else.

ngraham Don't know if you've been reading this, but another one of these options that gets me is the double click/single click location. On single click distribution setups one of the first things I do post-install is go to Input Devices>Mouse>stare at the screen like a moron as I remember that I need to go to>Workspace Behavior>General Behavior.

Except for Animation Speed and visual feedback, everything under General Behavior is in relation to mouse/trackball/pointing devices: tooltips, single/double clicking, and scroll bar clicking could probably be moved to the mouse input page.

Either that or move all the keyboard controls, etc over to Workspace Behavior. All those keyboard tweaks are on the Keyboard Input pane. Either pointers should have their settings/tweaks under that pane or the keyboard stuff should be moved out. Also, for the sake of noting it, there's another scroll bar setting, Invert Scroll Direction, under mouse input and, IMHO, should be grouped with the scrollbar clicking options under Workspace Behavior.

Also, what's the "visual feedback for status changes" setting for? I kind of ROFL'd when I hovered the mouse over it and didn't get a tooltip describing it in more detail (I ROFL'd because the tooltip setting is directly above).

I think KDE needs a System Settings Audit as well as more tooltips added. As long as I've used KDE I should know WTF "visual feedback for status changes" means. Common sense says it's when title bars and whatnot get asterisks, text goes italicized, etc...

[ngraham]

We can't move those to the mouse settings page because they're not mouse settings; they're *pointing device* settings. They applies to touchpads too. However we don't have a combined "Mouse & Touchpad" page where it could logically live, which is why it's not in either of those. I have proposed such a thing in https://invent.kde.org/plasma/system...gs/-/issues/15.