Reported by @Rishik at Telegram: The app doesn't show any UI(from 1499 to 1508).
Removing the deprecated `ICON_INSTALL_DIR` on macOS.
Using `KDE_INSTALL_ICONDIR` instead, following f7f3c01e.
Unicode text input from remote devices gives random texts because the plugin mistook the text encoding. Insert a Unicode 16 bits character each time instead of a UTF-8 character.
The API accepts the `UniChar` Unicode characters:
```c
void CGEventKeyboardSetUnicodeString(CGEventRef event, UniCharCount stringLength, const UniChar *unicodeString);
```
from https://developer.apple.com/documentation/coregraphics/1456028-cgeventkeyboardsetunicodestring.
`systemctl reboot`, `systemctl poweroff` and `systemctl suspend` only work on Systemd
I replaced them with the more universal versions (`reboot`, `poweroff`, and `suspend`) which work on Systemd, OpenRC, runit, SysVinit, and GNU Shepherd. These commands show up here:
Better patch to replace !218.
- Auto and quick detection of previous D-Bus instance;
- Remove private D-Bus compile definition, only use it on macOS without an existing D-Bus instance;
- Safe reboot after crashes because the indicator is not relating on the kdeconnectd to run a D-Bus session;
- Safe exit after clicking on `Quit` in the systray.
More details in commit logs:
Only enable private D-Bus on macOS because the other platforms do not
need them.
The app should be able to easily detect the session bus from the env
DBUS_LAUNCHD_SESSION_BUS_SOCKET from launchd through launchctl.
Because https://gitlab.freedesktop.org/dbus/dbus/-/blob/master/dbus/dbus-sysdeps-unix.c#L4392
shows that it is the only probing method on macOS with launchd.
The D-Bus session bus can be easily found from launchd/launchctl
with DBUS_LAUNCHD_SESSION_BUS_SOCKET env. It can be an external one
(installed from HomeBrew) or an internal one (launched by a previous
instance followed by a crash).
The indicator helper on macOS can now automatically detect whether we can use a potentially
(with launchd/launchctl env set, or KDE Connect macOS
private_bus_address set) existed and usable session bus.
If previous bus is usable, just try to launch the kdeconnectd with us.
Otherwise, launch a private D-Bus daemon, export the launchd/launchctl
env, and run a kdeconnectd instance.
Everything works better and quicker now :)
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
## 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.
Pairing is the result of explicit user action and requires interaction
Otherwise there is no visual feedback for a pairing attempt, leaving the user wondering why nothing happens
