The `NewWindow` Marionette command actually takes two arguments. They
are optional, and without them, Firefox will open a new *tab* instead
of a new *window*. Since we obviously want windows rather than tabs, so
as to place them on separate monitors, we need to explicitly specify
this when we execute the command.
When we create Firefox windows for each monitor, we need to move them to
their respective screens. The Marionette protocol provides a
`SetWindowRect` command that *should* move the active window (it doesn't
work for all window managers, notably *i3*).
For heads-up displays with multiple monitors, we're going to want one
Firefox window on each. To support this, we need to get a list of
connected monitors from the operating system and associate each with its
own window. Since Firefox may start with multiple taps open
automatically, we first close all but one and associate it with the
first monitor. Then, for each remaining monitor, we open a new window
to associate with it.
To maintain the monitor-window association, the `Session` structure has
a `HashMap`. When a naigation request arrives, the Firefox window to
control is found by looking up the specified screen name in the map.
Since the Marionette protocol is stateful, we have to "switch to" the
desired window and then send the navigation command.
I have tried to design the monitor information lookup API so that it can
be swapped out at compile time for different operating systems. For
now, only X11 is supported, but we could hypothetically support Wayland
or even Windows by implementing the appropriate `get_monitors` function
for those APIs.
If the URL specified in a navigation command results in a redirect, we
want to publish the final destination, rather than the provided
location. Thus, after navigation completes, we get the browser's
current URL and publish that instead.
The pieces are starting to come together. To control the browser via
MQTT messages, the `MqttClient` dispatches messages via a
`MessageHandler`, which parses them and makes the appropriate Marionette
requests. The `MessageHandler` trait defines callback methods for each
MQTT control operation, which currently is just `navigate`. The
operation type is determined by the MQTT topic on which the message was
received.
Several new types are necessary to make this work. The `MessageHandler`
trait and implementation are of course the core, reacting to incoming
MQTT messages. In order for the handler to be able to *send* MQTT
messages, though, it needs a reference to the Paho MQTT client. The
`MqttPublisher` provides a convenient wrapper around the client, with
specific methods for each type of message to send. Finally, there's the
`MessageType` enumeration, which works in conjunction with the
`TopicMatcher` to match topic names to message types using topic filter
patterns.
Dustin