Originally posted by skeevy420
View Post
KDE Gets A 2022 Roadmap - Plasma Wayland To Shine, Updated Breeze Icons
Collapse
X
-
Originally posted by mppix View Post
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.
Comment
-
-
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.X.org Developers Conference 2021 - September 15-17, 2021 - https://xdc2021.x.org/Slides and materials: https://indico.freedesktop.org/event/1/contributions/2...
Comment
-
-
Originally posted by ngraham View Post
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.Last edited by bug77; 04 January 2022, 11:30 AM.
Comment
-
-
Originally posted by ⲣⲂaggins View PostA 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.)
Comment
-
-
Originally posted by ⲣⲂaggins View PostA 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.)
After recent update, I am unable to set rotation from display settings. The X-server crashes: 77.782] (II) RADEON(0): Allocate new frame buffer 6400x2280 77.784] (II) RADEON(0): VRAM usage limit set to 133074K 77.786] (EE) 77.786] (EE) Backtrace: 77.786] (EE) 0: /usr/bin/Xorg.bin (xorg_backtrace+0x85) [0x55c918ca6875] 77.786] (EE) 1: /usr/bin/Xorg.bin (0x55c918ad0000+0x1d8375) [0x55c918ca8375] 77.786] (EE) 2: /lib64/libc.so.6 (0x7fa29273e000+0x56430) [0x7fa292794430] 77.786] (EE) 77.786...
Lots of strange and warped ways.
Originally posted by ⲣⲂaggins View PostWayland, 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.
Originally posted by ⲣⲂaggins View PostThat'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.
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.
Comment
-
-
Originally posted by Frenzie View PostThere'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.)
Comment
-
-
Originally posted by oiaohm View Post
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.
Comment
-
-
Originally posted by cl333r View PostYeah 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.
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...
Comment
-
-
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.
Comment
-
Comment