montis.git - Wetterhorn. A Wayland compositor based on XMonad.

	Commit message (Collapse)	Author	Age
...
*	Little test to make sure unloading the plugin still works	Josh Rahm	2024-02-11
\|
*	Added some more comments	Josh Rahm	2024-02-11
\|
*	Change up a lot of stuff.	Josh Rahm	2024-02-11
\| \| \| \| \|	Add more functions to the plugin interface and write some generators to generate an interface header file and the plugin's loading code.
*	Start making some more changes to harness and add plugin interface.	Josh Rahm	2024-02-11
\|
*	Fill out some of the README.	Josh Rahm	2024-02-09
\|
*	Fix Setup to not crash when a symlink exists.	Josh Rahm	2024-02-09
\|
*	Move the harness to its own CMake project.	Josh Rahm	2024-02-09
\|
*	Setup now builds wlroots in the .stack-work directory.	Josh Rahm	2024-02-09
\|
*	Put more logic in the build script.	Josh Rahm	2024-02-09
\| \| \| \| \|	The build script will now create the symbolic links to the binary and the shared library.
*	Just some minor changes. Proof of concept for state change.	Josh Rahm	2024-02-08
\|
*	Add wlroots submodule and add custom build commands to build it.	Josh Rahm	2024-02-08
\|
*	Made some more complex state in Wetterhorn.	Josh Rahm	2024-02-08
\| \| \| \| \|	Things are still purely for testing as I figure out how best to handle the ffi boundary, though things are starting to make sense.
*	Initial commit for Project Wetterhorn.	Josh Rahm	2024-02-08
	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.