I think it would be useful to have a GUI to configure APM settings, standby time, write cache settings, etc. for hard drives somewhere in Plasma (similar to the functionality that Gnome Disks provides). I'm not totally sure where it should be implemented though, if it should be a standalone app, or rolled into part of Powerdevil potentially (since it's somewhat power related?), or if there's somewhere else I'm not thinking of that it should be added to. I'm willing to try to implement the functionality, but I want to make sure it's done in a way that makes sense.
Harald, something for plasma-disks?
(In reply to Nicolas Fella from comment #1) > Harald, something for plasma-disks? I looked at that based on our matrix discussion but plasma-disks is a kinfocenter module so I wasn't sure about actual setting belonged in there. But on further thought maybe we add the functionality into solid where it's already handling disk stuff and then add a systemsettings KCM as a front end?
Why would it be useful to have a GUI?
(In reply to Harald Sitter from comment #3) > Why would it be useful to have a GUI? My use case is, I have a laptop that still has a spinning drive (I know). Default APM settings on my hardware cause the heads to park and unpark a lot and put extra wear on the drive, plus I can hear it. So setting the APM level up to 254 is a great way to solve the issue at least when I'm on AC power. Setting it persistently via command line is kind of a hassle. I can use hdparm but it only persists until the next sleep/reboot, or I can set it directly via udisks2 or maybe a systemd unit calling hdparm, but all of that requires a lot of documentation reading vs just clicking on a slider. I think TLP also can set APM levels for AC/battery but it can cause some issues with its other functionality, so not a lot of distros are shipping it by default. But it might be nice to be able to control those settings with other power settings.
I think you've made a case for making a better command line tool more than making a GUI tool there. As it were, creating the GUI tool is even more of a hassle because you not only need to figure out persistence but also first expose the necessary feature set in a digestible form (e.g. in solid as you've mentioned) plus write all the GUI code... and then, and that is the really concerning bit, someone has to maintain all of that. To answer Nico's question: this could probably go in plasma-disks, but I'm not convinced we'll want it in plasma at all. It is an incredibly niche use case that I don't see paying off on the amount of code it'd require. Putting it in the default feature set of Plasma seems a bit far out. If there really needs to be a GUI then a third party KCM outside plasma seems a much better fit - this could still live on KDE infrastructure mind you and be released as part of the KDE Gear.
Fair enough, that makes sense. Plus if someone really wants a GUI they can use Gnome Disks, chances are they probably have all the GTK stuff installed for something anyway. I think I'll go ahead and close this and I can just stick the relevant udisks2 file in a backup in case I ever reinstall my OS before I get a better laptop. ;)