Bug 509471

Summary:	Unavailable items on the login screen are disabled rather than hidden
Product:	[Plasma] plasmashell	Reporter:	Andrew <lostdharma>
Component:	Theme - Breeze	Assignee:	Plasma Bugs List <plasma-bugs>
Status:	CONFIRMED ---
Severity:	minor	CC:	djmenig, kde, kde, nate, visual-design
Priority:	NOR
Version First Reported In:	master
Target Milestone:	1.0
Platform:	KDE Linux
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Andrew 2025-09-13 22:11:03 UTC

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.

Comment 1 David Edmundson 2025-09-14 20:43:38 UTC

can you print the output of:

qdbus --system org.freedesktop.login1 /org/freedesktop/login1  org.freedesktop.login1.Manager.CanHibernate

Comment 2 David Edmundson 2025-09-14 20:44:13 UTC

can you confirm this problem is specific to SDDM?

Comment 3 Nate Graham 2025-09-15 13:53:38 UTC

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.

Comment 4 Sune Vuorela 2025-09-15 14:06:20 UTC

(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();
}

Comment 5 djmenig 2025-09-22 19:13:03 UTC

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.