Overhaul Solid
Open, Needs TriagePublic


Solid is this massive library for querying everything hardware.

It can be used to enumerate your Batteries, Processors (!), Network Shares, Optical Media, and other bits. Its API is inherently synchronous and likes to block doing tons of DBus calls. It was also written in a time before smartphones (there's only "Portable Media Player") or DBus ObjectManager (does a lot of individual property fetching).

I propose to simplify Solid and reduce it to basically querying batteries and storage (optical drives, removable storage, network shares) and giving it an asynchronous API.

Ideally, there was also a way for different backends to combine their device data. For instance, UDev can find a phone through PTP and then it might be found by some other backend. Currently, you get two distinct entries.

Also, backends as proper plugins would be useful, so we could have KDE Connect devices as first class citizens showing up in your device notifier as if they were a local USB drive, have their battery status reported like a mouse, etc.

broulik created this task.Oct 7 2019, 1:29 PM
nicolasfella added a subscriber: nicolasfella.EditedOct 7 2019, 2:11 PM

Another thing that needs action is power management and inhibition. plasma-workspace still uses KDELibs4Support due to lack of proper API for this (there is https://cgit.kde.org/solid.git/tree/src/solid/power but it's not enabled). Itinerary (https://invent.kde.org/kde/itinerary/blob/master/src/app/lockmanager.h) and KDE Connect (https://invent.kde.org/kde/kdeconnect-kde/tree/master/plugins/screensaver-inhibit) have code for suppressing screen lock/screensaver for FDO, Android, Windows and macOS, that should be abstracted in a library somewhere (not necessarily in the same library as the device stuff).

That's tracked separately in T11532

vkrause added a subscriber: vkrause.Oct 7 2019, 4:32 PM

Solid certainly needs attention for KF6 :)

  • Do you see powersave/screen saver inhibition and display brightness control in scope for Solid? If not, where would we put that in KF6? T11532 suggests Solid, this task would suggest something else IIUC.
  • How widespread is the usage of the things you suggest to drop? CPU enumeration sounds like something that's only there "because we can", but we should verify nevertheless to avoid repeating the same problem as with the Solid parts still in KDELibs4Support.

Not sure about that inhibition stuff, I'm torn between Solid, Notifications, somethingelse, maybe it could just be a KSomethingAddons class...

CPU enumeration sounds like something that's only there "because we can"

Pretty much, I think KInfoCenter uses it :D KRunner also used to use Solid, loading all of its backends, querying all of the things, just to figure out how many threads to use for querying … rather than, say QThread::idealThreadCount()