That’s actually not true if one selects “< Leave…” from the desktop right-button menu because it defaults to logout.
I agree the delay is good because it prevents interruption if it’s accidentally triggered.
True, though that action has been removed by default as of Plasma 5.27 (or 26? I can’t quite remember) precisely because of its ambiguity.
I get what everyone is saying. But my point is, one of the powers/values of Linux is the customizability. Why is it 30 seconds? Why not 5 minutes? Why not 30 minutes? A user can hit the space bar if they want it to continue before the 5/30 minutes are up.
I personally think this should be user customizable and persistant through updates. It doesn’t even need a GUI for editing – it’s okay to have text conf files.
But that is my opinion.
Most things in Linux that are customizable could have some “sane” default and most folks wouldn’t need to change it. The fact that they can change it, and have changes persist, is one of the reasons Linux is powerful – IMHO.
But I get that y’all feel my view/opinion is in the minority. That’s okay. I was just saying what I think. No need to mind me.
2 Likes
If you’re really triggered by this, sometimes with KDE plasma it is possible to tweak things for which there is no UI. If you can find the QML involved, you can hack it, and if it lives in C++ and is defined as a global, you can pre-load a .so with the setting you want.
(I find the 1 Hz blink rate of cursors in plasma to be anaemic, wasting 500 ms of my in zone time when I look for the cursor. There was a setting in Qt 4, in some file named something like, “TrollTech.conf”. But, a 10 line .cpp file compiled to .so and it’s good.)
I’m not so triggered that I want to go code or recompile things. I am just a regular end-user sharing feedback on the KDE experience. 
For now I’ve disabled it.
If I am triggered by something, it’s the lack of native support for a screensaver. I really wish that was there.
They are only hidden because, they are, well, erm, hidden.
Take the OSD timeout for volume control…
Fixed 1800ms timeout…
If I don’t want it to hang around long after the 300ms it takes you to acknowledge that the volume has altered, then I’m stuffed with a icon covering part of the screen for a second longer than I need without editing the OsdItem.qml file.
What would be wrong by “grouping” the settings like that in a file in the base directory of the theme?
They could be altered by anyone without needing to crawl through code. Also, programs could parse the file and build up their own list of possible customisations to present to the user - without having to know anything about the theme itself - thus making them “unhidden” :-).
If the user has a corresponding /.local/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/themedefaults (for example) file, values there override those in '/usr
1 Like
I personally wouldn’t mind a toggle for this either. It’s just not a feature I care to implement (or maintain), but unless I’m missing something it’s relatively simple to do so.
The knowledge requirements are:
- knowing about Q_PROPERTY()
- knowing how to expose a C++ option to QML (there’s an intermediate QML Udemy course by Daniel Gakwaya that’s cheap and worth it for this)
- knowing how to read from and write to files with KConfig
The thing I don’t understand is why is this in Breeze lol
3 Likes
I echo this sentiment. The notion that everyone thinks/operates/works the same or has the same needs is rather insulting. I’m faster than others at some thing, and I’m slower than others at something. Forcing me to deal with what works for “most” is, IMHO, not the Linux way.
1 Like
See Reddit - Dive into anything for a permanently working (up until any file structure changes in logout.qml happens) solution
I looked at the Reddit solution and it’s not ideal. You also run the risk of something breaking if a setting is updated in the original Logout.qml and this is not properly accounted for in the copied Logout.qml.
IMHO, KDE is about customization and this setting should be more readily exposed (I get that this might be a setting that’s not frequently changed, but KDE has 10^3 of these such settings and the majority of KDE users appreciate this level of customization. Alternatively, make the default more sane and change the 30 second default to something shorter (what percentage of KDE users are still using spinning rust HDDs on their desktops?).
1 Like
Amen. My thoughts exactly.
1 Like
BTW, why does that screen allows me to “change my mind” (e.g. “reboot” instead of “poweroff”), instead of a simple confirm-with-countdown screen/dialog? It seems to me that either Kickoff has all these reboot/poweroff/hibernate… buttons and the logout screen offer no choices, or Kickoff has one “leave” button then I choose the action in the logout screen. So what user scenario is the current (somewhat redundant) design targeting?
I don’t know. It’s a bit weird to me as well TBH.
A topic for another thread, though.
This hostility to the concept of users having control over their systems is a most unfortunate turn which the development of Plasma has taken in recent years.
It would be nice to be able to increase the timeout to 120 seconds, for example, but the developers know better than you how you should use your computer.
3 Likes
Let’s not go down the “developers don’t want you to do this” road, this clearly seems to me as a matter of “someone needs to be interested in this, implement it, and maintain it”.
If people are really interested in this feature but do not want to work on a fix, the Sponsored Work category is there for this.
3 Likes
Genuine question, is that how KDE development work? I would have assumed/thought there is some tracker with feature requests and bugs that is then prioritized and story boarded by key KDE players. So it would be a matter of regular users submitting a feature request or voting on it, and then the key KDE players prioritizing based on all the other variables?
You might be interested in some of these articles where I’ve written about how things work inside KDE:
1 Like
For these “most users probably don’t care, but a few might want to change it” numbers, instead of making a config UI for it, which probably requires, as you said:
knowing about Q_PROPERTY() knowing how to expose a C++ option to QML (there’s an intermediate QML Udemy course by Daniel Gakwaya that’s cheap and worth it for this) knowing how to read from and write to files with KConfig
Perhaps we can have a global registry that a user can set non-default values for all these numbers, like Windows registry, about:config in Firefox, and dconf in Gnome? So you just need to replace the “30” in the source code with something like get_from_registry("org.kde.plasma.plasmashell.lockscreen.timeout", 30).
That would significantly lower that barrier.
Yes, Nate talked about “bit-rot” with these hidden settings. But if Firefox managed with its much larger user base, perhaps it’s not that bad after all?
Registry or not (we use KConfig which writes to config files, which would render virtually the same result as a registry), one would still need to implement a configurable setting. As it stands, as far as I know, the setting doesn’t exist.
The order of things is like so:
- The feature exists and has a hardcoded value ← we are here
- The value becomes changeable ← this still needs to be done
- The value is exposed via KConfig ← this still needs to be done
Sure. As you can see above, users can find where in code to change, and if it can be done with a one-line change, I’m pretty sure that plenty of pull requests would be coming to KDE. The question is, would KDE developers, in general, accept those one-liner pull requests?
As about KConfig, I’ve added a few KConfig options myself. It requires changing at least two files, usually more. My goal is that you only change one line in one file for a hard-coded number, like you replace "Free disk space" with i18nc("Free disk space").
And these (rarely changed) default values shouldn’t mix with normal options in KConfig. They should be centrally stored, so a user can easily see (and revert) all defaults he changed in an editor. And they should be attached to bug reports and crashes.
I’d be happy to implement such a framework and editor. But still, the question is: would KDE developers, in general, accept those one-liner pull requests that replace a hard-coded number with a “hard-coded number that the user can change”? If changing the number breaks things, then it’s the problem of the user who did it, and you are not required to support any number but the default.
1 Like