Links can now created by dragging in both directions, so now from an input port to an output port, too.
The drag-n-drop handlers now use dedicated types for each direction, so that no mismatched things can be dropped on each other.
Control points are now offset by half the x distance of the start and end points instead of a constant,
which makes the curve scale better with varying distance.
While the properties for a links node ids are not always set, they always are in the link info.
Also, the work done in this commit will easily allow to get the format of links and ports later,
so that we can get the format of them much more reliably,
and we can also get notified of changes to an existing global via the info callback.
This is more reliable than assuming the link carries the id of its nodes, as there have been cases where a link was created without those
properties set.
Instead, we can just pull them from the state via the port ids of the link.
Glib MainContext is now aquired manually because a change in gtk-rs would lead to
a panic when attaching the receiver otherwise, because gtk::init() doesn't
"leak" the default main context anymore.
Revamp the node dragging implementation, moving it into the GraphView
widget.
When a drag is initiated, the node widget's current position is stored.
Whenever the drag gesture is updated, the node widget's position is set
by adding the relative drag vector to the position at the start of the
drag.
A drag gesture on the node widget rather than the GraphView widget was
considered, but this seems to lead to a weird flickering effect when the
node is moved while the drag gesture on the node is active.
To avoid interfering with the drag handlers on the ports, check if the
GraphView drag gesture targets a port, in which case the handler does
nothing.
This extends the `Application` struct to keep more advanced state.
This state is then used to determine the needed information to create
or delete a link between the two connected ports.
A message to create/delete the link is then send to the pipewire thread,
which executed the request.
The `View` sturct was mostly a layer of indirection, and the controller benefitted by absorbing the gtk::Application
subclass parts, so now those two are merged into a new gtk::Application subclass.
The pipewire loop now runs without interruption in a second thread and communicates with
the GTK thread via a channel in each direction, instead of checking for events once a second and using callbacks.
This allows changes to appear instantly in the view, instead of having to wait.
The controller still determines the ports media type, but instead of coloring
the port itself, the media type is passed to the constructor, which then colors the port.
The new architecture.md file contains a birds-eye overview of the top-level architecture
using box-drawing characters, but does not go into detail yet.
struct PipewireConnection is now decoupled from any other components, another component (the controller)
can receive updates by registering a callback.
struct PipewireState has been refactored to a struct Controller.
It still keeps state and manages the view, but now also actively requests updates from the pipewire connection via callback.
This updates all crates to their newest release.
For pipewire-rs, this includes bumping the version to 0.3, which means this comment has to fix a few breaking changes, but nothing big.
0.3 also lets us create and delete remote objects, which will be needed for link creation and deletion.
