dustin/hudctrl/pipeline/head There was a failure building this commitDetails
When a makes a *POST /screen/{name}/navigate* HTTP request, the URL list
is updated and saved to the configuration file. This provides a
mechanism for configuring the URL list, since it is now part of the
display configuration file and not a separate file manged externally.
When the display host updates its monitor configuration by making the
*PUT /display/monitors* HTTP request, the configuration is now saved to
disk. This will allow the controller to "remember" the configuration
the next time it starts up.
The biggest issue with the HUD controller right now is how it handles,
or rather does not handle, reconnecting to the display after the
controller restarts. Since it is completely stateless, it does not
"remember" the display configuration, and thus does not know how to
connect to the display or what its monitor configuration is when it
first starts. If the display is already running the the controller
starts up, it will not receive the request to initialize the display
until the display reboots.
To resolve this, the HUD controller needs to be able to load the display
configuration and initialize the display any time it starts up. As
such, the `HUDService` class now attempts to load the state from a JSON
file in its startup hook. If the file is available and valid, and
specifies the address and port of the display host, the controller will
open the Marionette connection. If the file also contains valid list of
monitors, the display will be initialized.
The URL list is now also read from the same configuration file, so as to
avoid having to manage multiple files.
Older versions hard-coded using the `AF_INET6` address family, even for
IPv4 addresses. While this "worked on my machine," it did not work when
the application was deployed to the Kubernetes cluster. Either cri-o or
the Debian-based *python* container image must disable this somehow.
The GUI now allows controlling the location of the screens by entering a
new URL in the text field. Upon submitting the form, the card will
refresh with the updated screen information and screenshot.
The *POST /screen/{name}/navigate* path operation allows the client to
request the screen navigate to a different URL, specified by the `url`
form field.
The GUI shows a screenshot of each monitor, as well as the title and URL
of the page being displayed. There's also a button to trigger a page
reload on the remote machine.
Any time we need to switch Firefox windows, we need to use a lock to
prevent multiple simultaneous requests. If we do not, interleaved
Marionette commands may result in performing operations on the wrong
window. For example, making two simultaneous requests for screenshots
is liable to return the wrong window for one of them.
The *GET /screen/{name}/screenshot* path operation returns a screenshot
of the specified screen as a PNG image. If a value is specified for one
or more of `height`, `width`, or `ratio`, then the image will be resized
accordingly.
The *GET /screens/* path operation now returns a mapping of monitor
names to screen properties. This matches the new behavior of the *POST
/screen/{name}/refresh* operation.
Poetry does not install local path dependencies in "editable" mode by
default. Instead, it builds them and installs them into the venv like
any other dependency. This means that changes in the local copy are not
picked up.
In order to be more precise about which screen will be refreshed, the
*POST /screen/{number}/refresh* path operation has been changed to *POST
/screen/{name}/refresh*. It takes a monitor name as the key instead of
an array index.
Instead of hard-coding the list of URLs to open, we'll read it from a
JSON file on the disk. The file contains a mapping of monitor names to
URLs, e.g.
```json
{
"HDMI-1": "http://my.site.one",
"HDMI-2": "http://my.site.two"
}
```
Dustin