We were using the plugin infrastructure to tell the name of the plugin
we were configuring.
Since this doesn't make any sense, just let the kcms themselves define
where they want their settings to be.
This fixes a regression from when we ported away from using KService to
list them. e365e1b35c
(cherry picked from commit 21dbf0410f)
## Summary
Fix crash in kdeconnect-sms if a conversation contains a message which has no addresses.
I am not sure why this would happen and there's probably something which should be fixed on the Android side to ensure that every message has addresses, but this is an easy fix to prevent user-reported crashes.
BUG: 449719
## Test Plan
### Before:
kdeconnect-sms crashes upon selecting a conversation with a message with no addresses
### After:
kdeconnect-sms does not crash
## Summary
On MacOS the system tray icon is off-color because it uses the gray-colored `kdeconnectindicatordark` icon which does not match the rest of MacOS.
BUG: 430226
I've used two patches to fix this:
1. Always use the status `KStatusNotifierItem::Passive` on MacOS. `KStatusNotifierItem` will only mark the icon as a mask (which is needed to allow it to dynamically switch between light and dark theme) [if the status is passive](cff7c337ab/src/kstatusnotifieritem.cpp (L1079-1081)).
2. The above should theoretically be enough to fix the issue and I swear at one point it was all that was needed. However, to fix this issue in my dev environment I also needed to pass in a `QIcon` with `setIsMask(true)` instead of setting the icon by its name. And I also use the `kdeconnectindicator` instead of `kdeconnectindicatordark` icon.
## Test Plan
The icon now renders in the correct color, regardless of whether devices are connected:
 
## Future work
Once I've verified this PR is working in the right direction, I want to look into making the icon gray (and hopefully a much easier-to-see gray) when no devices are connected!
For example, WireGuard, when not connected, looks like this:
 
P.S. I've been testing off the v21.12.2 tag since the master branch doesn't compile for me, so I haven't tested this change on the latest dev commit. But there should be no conflicts.
This makes the standalone KCM dialog consistent with the same KCM
when launched via kcmshell, systemsettings, or even other modules.
The dialog is required so it doesn't need to depend on kde-cli-tools.
## Summary
I've added a call to [`dialog->raise()`](https://doc.qt.io/qt-5/qwindow.html#raise) when launching the configuration dialog.
This is intended to fix a MacOS bug where the configuration window launches behind other open windows, but this call shouldn't harm operating systems as well.
BUG: 416050
## Test Plan
### Before:
Configuration dialog launches behind other open windows on MacOS.
### After:
Configuration dialog launches over other open windows on MacOS.
