| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
| |
As a part of this, I changed the file layout to:
rt/ - the Montis runtime
plug/ - the Montis plugin
wlroots/ - wlroots
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This monad allows keybindings to look and feel like one is writing
blocking code with constructs like:
key <- nextKey
when (key == x) $ do
key2 <- nextKey
...
...
but this code does not block or do any io shenanigans, it under the hood
just changes the handler on the state. It seems pretty awesome and opens
the doors for some pretty expressive key bindings.
|
| | |
|
| |
|
|
|
|
|
| |
This adds new layout configuration, preparing for actually using the
layouts. This also restructures the code and tries to keep code
interfacing with the foreign structures together and rename them to more
sensible names.
|
| |
|
|
| |
The plugin now passes the key events to the Wayland clients.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Add more functions to the plugin interface and write some generators to
generate an interface header file and the plugin's loading code.
|
| | |
|
| |
|
|
|
| |
The build script will now create the symbolic links to the binary and
the shared library.
|
| | |
|
| |
|
|
|
| |
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.
|
