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.
- 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.