I prefer lists to always be one item per line and in alphabetical order.
One item per-line makes merge conflicts less likely in the future.
Alphabetic ordering should mean any duplicate entries become obvious to
a human adding items.
Other orderings that future editors can easily spot and comply with are
fine and if there is a good reason to keep stuff bunched up (saving your
scroll wheel is not one) then that is fine too. I just use this as a
"Do the following by default" guideline.
Copy the current set of required packages from
https://github.com/debauchee/barrier/wiki/Building-on-Linux
sudo apt install git cmake make xorg-dev g++ libcurl4-openssl-dev \
libavahi-compat-libdnssd-dev libssl-dev libx11-dev \
libqt4-dev qtbase5-dev
This is following a failure of:
E: Unable to locate package libxtst-dev
From the AppVeyor build. The Travis build is debian, the AppVeyor one
is Ubuntu 18.04 at present.
Syntax errors behave strangely when the yml parser stops being involved
and Power Shell or Bash take over. This error said:
sh sudo apt-get update && sudo apt-get install \ libxtst-dev
qtdeclarative5-dev libavahi-compat-libdnssd-dev
sh: 0: Can't open sudo
Command exited with code 127
When I pushed AppVeyor reported:
Error parsing appveyor.yml: "environment" section must be a mapping.
(Line: 7, Column: 13)
I assume this means they cannot be empty. I had left only commented out
lines in it.
The AppVeyor system does not work in my fork of the project. To make
the build common between forks and the main, a .yml file should be used.
Outline the sections and basics in some comments as described in the
AppVeyor getting started notes. Copy the build steps from the current
.travis.yml file.
Once the Linux builds are working, I can start guessing at how to get
the Windows one running as well.
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.
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.
I build barrier on windows from SSH, as such, I need a way to invoke the "Developer Command Prompt for VS 2017" without a GUI. This simple one-line batch script gets the job done. I thought it might be handy to upstream it.
process I use to build on windows:
```shell
$ ssh owner@10.0.0.209
owner@DESKTOP-C2IV8E5 C:\Users\Owner> cd Documents\GitHub\barrier\
owner@DESKTOP-C2IV8E5 C:\Users\Owner\Documents\GitHub\barrier> pre-build.bat
owner@DESKTOP-C2IV8E5 C:\Users\Owner\Documents\GitHub\barrier> clean_build.bat
```
Done in order to match the size specified in src/gui/src/SslCertificate.cpp
Also see Debian bug #907528http://bugs.debian.org/907528
Related to Barrier Issue #126
Thomas A. F. Thorne
Adrian Lucrèce Céleste
jwestfall
Girts Folkmanis
Miroslav Lences
Moron
Robert Sandell
Dayne Broderson
Chris Simons
Monika Kairaityte
Povilas Kanapickas
Christopher N. Hesse
Epakai
walker0643
walker0643
Josh Stone
Pawel Bogut