The "Apply" button in the main window calls stopBarrier() immediately
followed by startBarrier(). The startBarrier() function reloads the
configuration. The fact that the "Apply" button applies configuration
changes is incidental; the "Start" button also applies new settings.
"Reload" more accurately describes the function that the button
performs.
Issue #284
Unlike other settings, the "Enable Clipboard Sharing" setting of the
ServerConfigDialog does not persist when the barrier application (GUI)
is stopped completely and restarted. Add the necessary code to the
saveSettings() and loadSettings() functions.
The system tray will be a nice to have. Everything should continue to
operate in a satisfactory manner without it. Log the warning but do
not interup the user with the message.
It is not essential that the system tray exists in order that the
application contuinue to function. Reduce the number of retry
attempts which will reduce the time the application appears stalled
at startup.
This is part of the work on making the app work without the need of
system tray support as described uner #155.
Adds the [preserveFocus configuration](https://github.com/symless/synergy-core/wiki/Text-Config#Focus_Preservation) item to the GUI configuration screen.
This is useful if you want to control a system that you are not the only user of. For example, I use barrier to control my HTPC computer sometimes, but I don't want Kodi to lose focus when my cursor leaves the screen since it will cause other inputs (i.e. CEC Remote) to stop working.
* make waitForTray() report a proper status - the return value was not
used until now anyway (it would always return true)
* depend on the system tray availability for auto hide
On my system (Fedora 29 with Pantheon Desktop), on a clean install the GUI
would auto hide itself on startup, but due to no system tray being
available I could never make the GUI appear again.
This change disallows auto hide if the system tray is not available.
Users who don't want the GUI can just start barriers/barrierc instead of
the main barrier executable, so this should not break existing workflows.
unixes when they are killed from the GUI with QProcess's close(). the
stdin stream is going completely unused (though the stdout stream is
not) so use stdin to send a shutdown command. this solution avoids all
the nastiness and overhead of using shared memory, mutexes, condvars,
etc. just to communicate "stop" from one process to another