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.
- Move the device combobox to the global drawer
- Move search field and new button to header
- Use Kirigami SearchField instead
- Don't switch focus away from search field when typing
- Give the New button an icon
- Clarify the search field text
- Center messages view loading indicator
- Make send and attach buttons stick to bottom of text area
- Make cursor an I-beam when hovering over text area
- Move send button to the right
- Give proper padding to messages view top
- Move refresh action to global drawer
- Show refresh button directly in loading message where it is most useful
| Before | After |
| ------ | ------ |
|  |  |
|  |  |
|  |  |
cc @teams/usability @teams/vdg
* Instead of using the kcm to signify kde connect, just call it kde
org.kde.kdeconnect. org.kde.kdeconnect.kcm.desktop didn't exist anyway.
* Specify launchables for optimal integration in software centers.
* Specify which dbus service it's offering, in case it ever is
necessary.
* Specify the oars, stating there's no offensive content of any kind
offered through KDE Connect.
