Loading the icon for the button from resources ceased to work (maybe when
switching to `PlasmaComponents3.ToolButton`). This change works around the
problem and the old icon no longer needs to be bundled.
If there's a configured and local Syncthing connection and we're on a
non-UNIX platform which doesn't support SIGTERM (basically Windows) it
makes sense to use the REST-API instead. That's likely better than just
terminating the process forcefully.
This doesn't cover the stop button within the launcher settings yet because
from this context is isn't clear which connection is relevant as there can
be multiple tray icons/widgets but only one settings page.
* Use a process group / job object via Boost.Process to be able to
terminate sub processes as well
* Do not try to stop the process gracefully under Windows by posting
WM_CLOSE because this has no effect on Syncthing anyways
* See https://github.com/Martchus/syncthingtray/issues/94
The default of 32 px should be fine in most cases and when the UI is scaled
it is also automatically scaled. However, if one has a tray area or Plasma
panel with extraordinarily big icons like latte-dock it might still be
required to render icons at a higher resolution. This is hard to determine
programmatically so I'm just adding a manual setting.
Before this change syncthingwidgets unconditionally included the header
from libsyncthing so it couldn't be used as stand-alone library if
libsyncthing was disabled.
So far the backend libraries' include paths were relative within this
repository. This means the header files could not be used at their
installed location.
This change replaces them with "<>" includes to fix that problem and adds
a new include directory so building everything at once still works.
With this change it should be easier to actually split some parts into
another repository if this one would become too big.
The external inotify tool is likely not used anymore. It makes sense to
keep the concept of supporting additional tools because it might be used
in the future again. So it seems best to give the additional launcher a
more generic name.