Continues the work started in !396 by rebasing it onto latest master and
making the "send clipboard" button from the plasmoid invisible when
automatic syncing is enabled.
I didn't find a way to do the same in kdeconnect-indicator and
kdeconnect-app (why do we have 3 UIs???), so in those we always show the
option for now.
Unset launchctl env before running the new one, to avoid connecting through the old launchctl env.
Show a warn message for D-Bus connection failure on macOS.
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 :)
## 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.
## 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.
This KCM will have to get installed installed in the new plasma namespace eventually.
But considering that this app is part of the release service, we should not
depend on changes in a not yet released Plasma version.
Task: https://phabricator.kde.org/T14501
