lboklin
commented
5 years ago More proposal details:
Move nearly all of our Haskell code into two separate repositories defined below.
godot-wayland
Renamed from current godot-haskell-plugin. Contains:
- simula-wayland (unless we want to break that out too)
- the exported class GodotWeston which exports a toggle method for whether it should create 3D sprites from surfaces (default is not) and also a method for getting ImageTextures ready to be assigned to whatever the plugin-user sees fit
- the exported class GodotWestonSurfaceSprite for the optional creation of ready-to-go sprites like we have currently
- GodotWestonSurfaceTexture but renamed to WestonSurfaceTexture and it's no longer a Godot class, but a data type used by GodotWeston for translating Weston surfaces into ImageTextures
- a demo scene demonstrating basic usage of the plugin from GDScript as a POC
- misc future feature additions via an exported methods API
Simula
Proper main project, not a plugin. Haskell project resides in project root. Contains:
- no system-level dependencies (that goes into godot-wayland)
- compiled godot-wayland plugin binary in addons/godot-wayland just like addons/godot-openvr or addons/godot-openhmd
- window placement/manipulation logic
- UI (using Godot's UI capabilities) such as app launcher, indicators or other interactive elements
- a pleasant 3D environment
- input handling (high level Godot stuff - send raw keycodes to GodotWeston which handles everything relating to Wayland/Weston)
- the opt-in telemetry (preferably run-time option rather than compile time)
Caveat: The compiled godot-wayland plugin binary is going to have a lot of dynamic dependencies (system and Haskell libraries) unless we manage to reduce them somehow via static compilation or bundling. In that case people are going to have to compile it themselves.
The entirety of our code base currently resides in addons/godot-haskell-plugin/ even though the scope of the project is far beyond a simple plugin. I think it's worth to consider moving code which is not meant to be reused in other Godot projects as a plugin into its own Haskell project in the Godot project's root directory (as the main codebase for the Godot project).
For example, I propose separating the functionality specifically for launching the Weston compositor and creating textures from Weston surfaces into a small Haskell project which compiles a GDNative plugin like we do currently. An abstracted API with additional compositor functionality could be provided by the plugin via exported class methods. This plugin can be reused by any Godot project which wants to include a basic Wayland compositor.
The rest of our code is for creating an environment in which you can organize and interact with your Wayland application windows and as such it ought to be the main project. We can then utilize our Weston compositor plugin's exported classes as intended, via the Godot API.
This would help the separation of concern / code organization, accessibility for new contributors and the possibility for adoption by other Godot projects (and thus exposure). It also helps to contain system dependencies and the Wayland FFI in the compositor plugin, making it easier to build, distribute and hack on the main Simula project once you have the plugin in place.