Fixes high cpu usage spikes on win10.
When queue was containing messages of only non-QS_POSTMESSAGE type the
"while (m_buffer->isEmpty())" busy-looped in EventQueue::getEvent
since isEmpty was true (checked only QS_POSTMESSAGE message type),
but waitForEvent returned immediately (checked more message types).
Investigation shows that the difference was introduced in
https://github.com/debauchee/barrier/commit/dbfb04a6e
to fix a problem with bad behaviour of GetQueueStatus
Researching showed that a similar problem was fixed in Qt,
and the solution was
"pass different flags to GetQueueStatus depending on version of windows"
https://bugreports.qt.io/browse/QTBUG-29097
So this patch makes changes to a barrier non-GUI core similar to Qt fix.
QLength() may return 0 even if there are events pending because they
need to be read from the display socket in order to become visible. We
must use XPending() which will poll the socket if QLength() == 0.
Current code base don't use IEventQueue::isEmpty() method.
Remove it to simplify IEventQueue API and to remove confusion with
IEventQueueBuffer with same name.
The IEventQueueBuffer::isEmpty() and all its implementations kept unchanged
This changes the log level for several statuses (started server,
connected to server, server status:) from CLOG_NOTE or CLOG_INFO to
CLOG_PRINT so they will be printed to stdout regardless of the log
level. This allows the GUI to accurately report the status of the
`barriers` or `barrierc` processes in src/gui/src/MainWindow.cpp#L379-L399.
Setting the Fingerprint label to TextSelectableByMouse allows users to
copy/paste the fingerprint so it can be easily added to "TrustedServers.txt"
on a client machine (i.e. via SSH).
Errors where the socket address is in use will keep the server from connecting
with clients. This should be reported as an ERROR instead of a warning. Also,
if the retry time is shorter issues will be more obvious, since the error will
cause the log to scroll visibly.
Silences the "is calling TIS/TSM in non-main thread environment"
messages in the log when running a MacOS server as it is a red herring
that causes a lot of issues to be filed.
Commit 6c888437 made Qt5 mandatory for all builds when it is only
required for the GUI. There's already a find_package call in src/gui,
it just needed the REQUIRED flag to be added.
Sometimes -lpthread is not enough. This has caused build failures on
Gentoo Linux in the past.
The logic also seems needlessly complex. We check for HAVE_PTHREAD on
UNIX platforms even though CMake errors out if pthreads are not
found. Similarly, we have a fallback for HAVE_PTHREAD_SIGNAL being
false even though we always set it to true.
The commit a841b28 changed the condition for removing job from processing.
New flag MultiplexerJobStatus::continue_servicing become used
instead of checking pointer for NULL.
However for cases when TCPSocket::newJob() returns nullptr
the behaviour changed: earlier the job was removed, but after change
it is called again, since MultiplexerJobStatus equal to {true, nullptr}
means "run this job again".
This leads to problem with eating CPU and RAM on linux
https://github.com/debauchee/barrier/issues/470
There is similar windows problem, but not sure it is related.
https://github.com/debauchee/barrier/issues/552
Since it looks that the goal of a841b28 was only clarifying
object ownership and not changing job deletion behaviour,
this commit tries to get original behaviour and fix the bugs above
by returning {false, nullptr} instead of {true, nullptr}
when TCPSocket::newJob() returns nullptr.
The expected style for macOS menu bar images is a template image than
can adapt to the user's appearance settings. Also, high-res screens
("Retina" in Apple speak) need higher resolution images.
Based on /res/barrier.svg, I created black and transparent SVGs for the
three icon states. I had to remove some details to make the image scale
down to icon size without becoming too crowded, and I drew a new
checkmark and the transfer arrow.
Member initializers are always run in the order defined in the header.
This commit reorders them in the implementation so that their order
reflects their execution order.
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.
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.
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.
