This new method enables the ExperimentState class to update its
properties when new data has arrived via the updateExperimentState
command.

The logging function aliases cannot be const here because this screws
up the defaulted assignment operators.

This adds the common aliases also to this class in the library.

The ExperimentState class can now put its properties into the update
command. Only the token needs to be added later by the class that
requested the command object.

This was still missing from the collection of the state variables.

The software uses Pascal internally as this is the SI unit, but the old
guide to the real experiment uses Torr, so we add a conversion function
to display both in the GUI.

Hectopascal is identical to millibar, but Pascal is the SI unit, so we
go with it...

The same script as for server and client, but without artifacts because
uploading the static library doesn't yield much use.

This does not matter right now due to static linking, but in case the
common library is used as a shared library in the future, these types
have to be in the export table.

If a custom C++ version is selected, the integrated ROOT build should
also use this version to prevent any inconsistencies within the
application.

The pointer variables in the Qt event handlers can be const and should
therefore also be declared as such.

As ROOT provides sophisticated menus that a novice might screw up, this
adds the option to ignore any input from the user by not passing it on
to ROOT.

As ROOT provides sophisticated menus that a novice might screw up, this
adds the option to ignore any input from the user by not passing it on
to ROOT.

This adds the necessary ties between Qt and ROOT so that the user can
modify the content of the TCanvas as in pure ROOT.

If Qt redraws the GUI, this is forwarded to ROOT's canvas.

This instantiates TCanvas and draws the empty canvas on the widget's
surface area.

This class shall encapsulate a TCanvas instance from ROOT.

The code is inspired by this ROOT forum thread
https://root-forum.cern.ch/t/gvirtualx-addwindow-problem/25215/5
and this example posted there:
https://root-forum.cern.ch/uploads/default/original/2X/4/4f1f5269962b0622a04fa6093c805f5573669df4.gz

This action will allow the clients to select whether the target hole
should be open, closed, or covered with a gold foil.

This verifies the content of the JSON object and constructs a Command
instance with the parameters given there.

The first collection of methods was apparently incomplete, so it is
hereby extended.

This turns a command object instance into a JSON string that can be send
through the websocket.

This struct represents one command sent via th websocket connection in
either direction.

Writing the code parsing an incoming command has been partly written
already.

This enum contains all the commands currently foreseen for the protocol,
although the list may of course be extended later on.

In order to make the invocation of the log output method as short as
possible, this helper function creates a function object that stores a
component name and a log level.

For the case that the colors cannot be displayed properly, e.g. because the log
has been redirected to a file which is viewed in an editor, the log level is
also printed as text.

This class facilitates the log output on the terminal and displays
different log levels by using different colors.

This structure keeps track of key parameters like target position,
pressure, etc. of the experiment.

This adds the BoundedNumeral class template and its associated exception
that I wrote originally for libLedPulser2.

Sources:
https://gitlab.ep1.rub.de/dcs/libledpulser2/-/blob/dbdab89d5332c643905e8ef608a922ba9470c52f/src/boundednumeral.h
https://gitlab.ep1.rub.de/dcs/libledpulser2/-/blob/dbdab89d5332c643905e8ef608a922ba9470c52f/src/boundaryexceededexception.h

Due to a copy&paste mistake, the current year was given as “2020” in the
copyright notice at the top of the file.

The ROOT version currently in the openSUSE Science Repository which I
use to work on this application is compiled with C++11 and compiling
this application with C++17 causes problems with several main ROOT
header files.

Therefore, the C++ standard can be selected by developers while still
defaulting to C++17.

Both the client and the server will use various functions from ROOT,
especially the client will draw histograms and fit.

The ROOT libraries required for this are added as dependencies to the
common library, standard ROOT libraries like libCore are pulled in
automatically through the ROOT-internal dependencies.

This reworks major parts of the script to build ROOT from a submodule.

In addition, the dependencies between the various ROOT targets are now
handled properly.

This invokes the script added in the parent commit when the option
USE_HOST_ROOT_INSTALL is set to OFF.

This script takes the source code of ROOT in the submodule and compiles
it with options set to build a minimal ROOT installation as we only need
some basic stuff for this project.

After compilation, the script creates some imported targets for the ROOT
libraries.

Apparently the ROOT version we use is recent enough to support C++17 (my
previous knowledge was that C++14 was the maximum), therefore we use
C++17 throughout the project.

The stable release of ROOT – as of today 6.22/08 – is hereby added as a
submodule so that the project can be built independently from the host
environment and also on a Flatpak SDK and on Windows.

Adds a dependency on ROOT and the package discovery for it.

For now, the ROOT installation on the host system will be used, but the
option to have a fixed version of ROOT as a git submodule is underway.

If SOURCE_DIR is used, the submodule will read the version of the
superproject.

CURRENT_SOURCE_DIR should be used instead of SOURCE_DIR to make sure
that the script also works when the project is used as a submodule.

This changes the project configuration of KDevelop to use CMake for
build control.