--- /dev/null
+* WM client lib that implements afb calls to the WM
+* Most of the API
+X Application structure, whereas controller events should be forwarded to it?
+ Decorator? Proxy?
+X Loose coupling between API calls and the actual handler in the appliation,
+ perhaps convert the verb's json input into a nlohmann::json and pass it to
+ some app method which then in turn can return a Result<error, json> kind
+ of thing. The verb's entry point would then construct a reply accordingly
+X Design a sensible and lightweight representation of a Layout inside the WM
+ Appication.
+* Wm Objects (Layers, Screen, Surface, Areas?) Should be handled with IDs, only
+ Upon making the concrete calls shall the actual objects be resolved.
+* Implement an application configuration, possibly in /etc, must contain:
+ - json configuration names
display{d},
controller{},
outputs(),
- layouts(load_layout("../layout.json").unwrap()),
+ layouts(), //load_layout("../layout.json").unwrap()),
surface2layer(load_layer_ids("../ids.json").unwrap()) {
// layouts(load_layout("../layout.json").unwrap()) {
assert(g_app == nullptr);
g_app = this;
+
+ try {
+ auto l = load_layout("../layout.json");
+ if (l.is_err()) {
+ logerror("Coult not load layout configuration: %s", l.err().value());
+ }
+ } catch (std::exception &e) {
+ logerror("Coult not load layout configuration: %s", e.what());
+ }
}
App::~App() { g_app = nullptr; }