Pass a widget when invoking `QStyle::drawControl()`; the Windows 11 style
uses the widget unconditionally.
Considering the documentation explicitly states `The widget argument is
optional` and the default value for the function argument is `nullptr` this
is supposedly a bug in Qt.
* Avoid multiple definitions of `centerObj()`; this was very bad anyway
* Include `c++utilities/tests/testutils.h` upfront so the formatting
operators are included before CppUnit
* Remove the old approach to specify actions as it is lacking the `Actions`
key and doesn't allow customizing the executable name
* Add actions for most important use cases
Syncthing added shell completion in v1.27.3-rc.1 (commit
78db3af8c5e8bd08a9773b0c4da233a52ed4cfe6). This change integrates
that shell completion with Syncthing Tray's long existing completion (which
only supports Bash so far).
* Set content margins to take shadow effects into account
* Fix behavior when showing the QMenu not as `Qt::Popup`
* Prevent polishing as it would wrongly override our window flags
* Use the background color from the application's palette as the
background color from the QMenu itself is changed by the Windows 11
style
* Remember new size after user resized the window
* Remember new position after user repositioned window and using explicit
coordinates has been configured in the appearance settings
This might be useful on Wayland where positioning the popup is otherwise
not possible at all. Combined with a session restoration mechanism this
might actually be a feasible workaround. The user just needed to position
the popup once wherever it is wanted to show up and then the compositor
could remember that position.
Especially the resizing would also be useful on other platforms (and is by
the way also already possible when using the Plasmoid showing it as part of
the system tray Plasmoid).
Not sure why I'm getting
```
Fehler beim Abfragen der Syncthing-Konfiguration: Error transferring http://127.0.0.1:8384/rest/system/config - server replied: Forbidden
URL der Anfrage: http://127.0.0.1:8384/rest/system/config
```
one one of my setups but this kind of error can likely be ignored shortly
after the start similar to other types of errors.
* Do *not* build Syncthing in addition as standalone executalbe
* Explose instead all of Syncthing's commands via the library
interface
* Make all of Syncthing's commands (including `serve`) accessible
via Syncthing Tray's executable
* Remove copied code for directory creation and instead use
upstream's code directly
* Do not blindly override existing auto start entry
* Warn if an auto start entry exists but points to a different executable
* Allow removing such an entry explicitly
* Avoid overriding argv/argc via `CMD_UTILS_CONVERT_ARGS_TO_UTF8` in
Windows-specific code when processing arguments from a 2nd instance
* Move the other startup code to main as well as they are not needed when
processing arguments from a 2nd instance
* Improve debug logging
* Use `waitForBytesWritten()` instead of `flush()` when passing args as
recommended by the documentation
* Avoid use of `bytesAvailable()` as it doesn't work as expected in this
situation on Windows (likely it doesn't really work reliably on all
platforms); calling `readAll()` works and is simpler anyways
* Tested that `--replace` works as well; also the
`waitUntilGone && QFile::exists(fullServerName)` block is entered and if
the previous instance is taking some time it really waits until it is
gone
* Make functions in `main.cpp` static as they are not used by
other units
* Delete the `TrayIcon` via an extra parent object that is
deleted before the `QNetworkAccessManager` is deleted; otherwise
the destruction of `SyncthingConnection` (which aborts pending
replies) might access dangling `QNetworkReply` objects
* Improve error handling in `SingleInstance` code
* Allow to replace the current instance via the new `--replace`
argument; this may be useful when creating an installer/updater
Martchus
John Veness