Applications shouldn't use libwayland directly unless you're planning to implement your own toolkit and event loop and threading abstraction yourself. It's cert

Applications shouldn't use libwayland directly unless you're planning to implement your own toolkit and event loop and threading abstraction yourself. It's certainly a take to do things in the most complex way and then complain that you have to implement a lot of complexity. Off the top of my head, here are things that won't work that way unless you implement them yourself: - Networking. The socket(s) will block your program loop. - Audio. Has to be done on a separate thread with strict timing. - Background loading. Get ready for your program to hang when loading a large file. - Talking to any system services. Every common desktop uses dbus now. Really. Using sway on an embedded system without dbus is a niche. - Power saving modes. Without an event loop you always have to use sleep to poll yourself manually, and that's wasteful. - Simulations, physics, or anything else that requires a constant tick rate. These are dependent on running the rendering in another thread. - Accurate timers. Any issues with any of the above will block a timer from firing. There are probably a lot more too. What seems "lightweight" first can turn out actually not be lightweight at all.