By commenting out the parameter name, we get compile-time checks
Also, we can omit them for slots and Qt will not forward the parameters.
In case we had TODOs next to the code, I kept the Q_UNUSED statements
for now.
- Using QLatin1String when concatinating strings is faster, because they
are more lightweight. For the resulting string, we need to allocate
new memory anyway
- Use QLatin1String overloads where they are provided by Qt APIs
- Just use const char* for log messages, the quoting of QStrings is not
needed
- Make sure to reuse string results when possible
The rationale is explained in https://planet.kde.org/friedrich-kossebau-2023-06-28-include-also-moc-files-of-headers/
In case of KDEConnect, it impressively speeds up compilation. Before it
took 390 seconds on a clean build and with this change it took 330 seconds.
This is due to the mocs_compilation having to include the header files
and thus all their headers. Due to the lots of small plugins we have,
this means that the same headers must be compiled plenty of times.
When we include the moc files directly in the C++ file, they are already
available.
This makes it easier to read, because we do not have to handle a list of
files that get added to the targets. In other KDE projects, we also
prefer the target centric approach.
In case one wants to reuse the same category in multiple places, it
would be best to create a small static lib. But for now, this is not
needed.
- Add dummy args param to QProcess::startDetached
- Remove logging category from inline snippet. This was removed due to
being unused in non-windows builds.
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
