Follow-up to: https://invent.kde.org/kde-linux/kde-linux/-/issues/301 SUMMARY There's a greyed out hibernate button on login screen and it shouldn't be there. According to the comments from the link above, the issue was first introduced in https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/3120 and the resolution is not as "open-and-shut" and needs more discussion.
can you print the output of: qdbus --system org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager.CanHibernate
can you confirm this problem is specific to SDDM?
This isn't a bug, but rather a design decision that was fairly well hidden before, and has become more visually obvious. The design decision is to disable rather than hide buttons for actions that can't be performed. It's not common for sleep, shutdown, etc to be disabled, but it's more common for hibernation. The question is whether we want to continue to disable these buttons, or hide them instead. The HIG is not clear on the matter.
(In reply to Nate Graham from comment #3) > The question is whether we want to continue to disable these buttons, or > hide them instead. My Opinion (which of course always is the correct one) is that if the user might be looking for the feature/button/.. it should be there but disabled (maybe a hover text to inform the user of 'why'). Also if it is a thing that the user might want to do in a common case, make it disabled, maybe with a hover text to explain how. If it is unlikely the user want to do it and need to do it, it is just visual clutter. It can also be conditional. That can lead to a bit complex decision trees of course: If(feature-B-is-selected) { if (frobnizzer-found) { button->onClicked(activateFrobnizzer); } else { button->setDisabled(true); button->setHoverText("Frobnizzer not found. Please get it available"); } } else { // Frobnizzer only makes sense if feature B is active button->hide(); }
FWIW, I came here to report this as a bug since it looked like an unintentional change where an icon was missing, or the icons were offset (not centered). Perhaps a solution to consider would be a setting within the SDDM KCM that could toggle what the recent merge added--that way the user or distribution can decide. Or at the very least, change the color so that all the icons have the same visibility.