3 ms·

One problem with dbus is that some compositors (for example sway) have a design goal of working in environments where dbus isn't available. And even if that wer

by thayne 4y ago

One problem with dbus is that some compositors (for example sway) have a design goal of working in environments where dbus isn't available. And even if that weren't the case it means applications need to deal with multiple asynchronous protocols, which isn't that big of a deal if you are already depending on a big toolkit like gtk, but for a lightweight application that is working directly with wayland (or, say a game that draws everything itself and doesn't use a widget toolkit), it adds a lot of complexity.

kaba0 4y ago
And how should such an environment signal power management requests reliably then, without the de facto linux way?
QUrprUd1nCeicw 4y ago
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.

by thayne 4y ago

kaba0 4y ago

And how should such an environment signal power management requests reliably then, without the de facto linux way?

QUrprUd1nCeicw 4y ago

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.