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.
build_installer.sh on OSX is responsible for populating Barrier.app to
make it viable to run and creating a dmg for release. However its only
works if you run it against a release build. This patch makes so you can
run it on a debug build and it will populate Barrier.app but doesn't
create the dmg.
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.
Its possible poll() will return that a socket is both readable and
writable. When this happens TCPSocket::serviceConnected() is
overwriting the result from doWrite() with the result from doRead()
This can cause a situation where doWrite() tried to notify that we
should stop polling if the socket is writable, but the doRead() result
causes that to be ignored. This results in a tight loop and 100% cpu
usage in SocketMultiplexer::serviceThread() as the poll() call
instantly returns that the socket is writable, but no one cares that
it is. The issue eventually corrects itself with enough mouse
movement/clicks.
