diff options
| -rw-r--r-- | TODO | 14 | ||||
| -rw-r--r-- | src/app.cpp | 11 |
2 files changed, 24 insertions, 1 deletions
@@ -0,0 +1,14 @@ +* 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 diff --git a/src/app.cpp b/src/app.cpp index 5ddcb8c..0bf4529 100644 --- a/src/app.cpp +++ b/src/app.cpp @@ -99,11 +99,20 @@ App::App(wl::display *d) 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; } |