| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| | |
|
| |
|
|
|
|
| |
The build system will now just download wlroots directly rather than
having it as a submodule. Submodules are really brittle and not well
supported. This is the much more correct approach.
|
| |
|
|
|
| |
Finally have coherent building on top of CMake. And installing actually
works. In addition we use a static wlroots to avoid version hell.
|
| |
|
|
|
|
|
|
| |
As a part of this, I changed the file layout to:
rt/ - the Montis runtime
plug/ - the Montis plugin
wlroots/ - wlroots
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Turns out the haskell geniuses already figured out how to encapsulate
such asynchronous control flow.
|
| | |
|
| |
|
|
|
| |
This will be useful for the future when I will implement macro-recording
functionality.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Specifically a way to reload the plugin and switch vterms. This is
important in case the plugin is borked and stops accepting keyboard, the
user can switch to a vterm, fix the plugin and reload it to get things
working again without running into data loss.
|
| |
|
|
| |
This is making better key bindings possible and awesome!
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Turns out that the one on Github is ancient and the project was moved
long ago ... which is quite annoying that. No wonder where all the
confusion was coming from.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
The plugin now passes the key events to the Wayland clients.
|
| |
|
|
|
|
|
| |
I was initializing the plugin twice, causing hs_init to be called twice
rendering the teardown call to hs_exit useless. Things finally appear to
be working as intended, and it's likely this plugin architecture will
work afterall!
|
| |
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
| |
Remove it as such!
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Right now nothing interesting is happening, but the new tinywl
implementation is successfully loading a plugin and calling a handler
for 'handle keybinding', which is pretty slick.
|
