| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
The plugin now passes the key events to the Wayland clients.
|
| |
|
|
|
|
|
|
|
| |
This is done to cleanup the dangling reference to the opaque state
before unloading the plugin.
This fixes the problem where the runtime gets a "strange object" during
garbage collection after hot-reloading the plugin while keeping the RTS
running.
|
| | |
|
| |
|
|
|
|
| |
This is done by passing an interface to the plugin from the harness. The
plugin can then request the harness do some things (such as reload), and
the harness will do that.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Now if one tries to execute the built binary with 'stack run' or by just
executing it, a helpful message prints to the screen instead of the
segmentation fault that normally happens.
This technically makes things not portable to other architectures, but
it's all just window dressing and can be taken out if need be for other
architectures.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
reload.
It turns out I could actually remove the metaload handler from the
plugin interface. As things turn out, when fully unloading the shared
object and reloading it, the Haskell runtime no longer complained. This
makes things much simpler, which is great.
I do wonder if I'm going to run into issues because of this, but I'll
cross that bridge when it's burning.
|
| | |
|
| |
|
|
|
| |
Add more functions to the plugin interface and write some generators to
generate an interface header file and the plugin's loading code.
|
| | |
|
| |
|
|
|
| |
Things are still purely for testing as I figure out how best to handle
the ffi boundary, though things are starting to make sense.
|
|
|
Project Wetterhorn is an attempt to make a Wayland compositor inspired
by XMonad. This project is different from other Wayland compositors in
that one of its core tenets is dynamic reloading of as much code as
possible.
The architecture is going to be:
- A harness, written in C, supplies the basic components to create a
Wayland compositor. This will be modeled on tinywl, sway, dwl and
others and use wlroots as its main abstraction to wayland.
- A dynamic library, written in Haskell, will provide bindings for
handling events and managing the windows. This dynamic library can
be recompiled and reloaded at runtime, allowing the user to write
their 'configuration' in Haskell, much as XMonad, but without
needing to reboot the whole compositor.
The boundaries of responsibilities between the harness and the plugin
will be an evolving matter, depending on how important the dynamic
reloading is for that specific responsibility and the need for raw
performance.
I chose this architecture as a compromise. With this architecture,
dynamic loading is achieved without the need to define a whole protocol
around controlling the window management, but this also gives the plugin
the full ability to control the compositor because it is literally a
part of it making anything possible in theory, which is a huge benefit.
|
