D-Bus is the standard way for applications to communicate with one another. But the EWMH, supplemented for our purposes by libwnck, is the standard way for applications to communicate with the window manager. GNOME bug 531512 raises the suggestion that even window manager communication should be done over D-Bus, or at least that D-Bus should be an alternative to the EWMH.
There are two main questions to answer before we make any decision here:
- Does this buy us anything? Are there people whose lives will be made easier if they can do what they want over D-Bus, without having to include X libraries to use the EWMH? Is this enough to justify the additional complexity in each window manager?
- Can we keep this standard? EWMH works with almost all window managers. Switching to a D-Bus-based system brings the risk of fragmentation.
A third option: We could have a separate application which provided a D-Bus service that knows how to send and receive EWMH messages. Such an application could be run in conjunction with any EWMH-compliant window manager. Here’s a quick proof-of-concept your chronicler threw together in a few hours in Perl; let us know, gentle reader, whether you believe it’s worth developing any further.
Photo © Salim Virji, cc-by-sa.
Long time no see! Welcome back, Thomas!
I guess pros of D-Bus are that people familiar with ordinary app programming should already be familiar with it; the details of X11 are pretty well hidden by GTK+ and Qt these days. Also, D-Bus supports introspection, so you can poke around with a tool like D-Feet in the (inevitable) event of inadequate documentation.
The cons would be having to create a sister spec to EWMH, or even a new version that describes D-Bus bindings as well as traditional X11 APIs, and waiting for people to adopt it.
Frankly, I think your Perl shim sounds like the best of both worlds – functionality available to D-Bus, without having to write extra code for every EWMH window-manager. Bonus points if it includes libwnck’s functionality into the same data model, too.
The existing EWMH system works perfectly with remote X, which I use extensively. D-Bus, not so well, assuming it’s even available on the remote machine. Which it frequently isn’t, since in my case the remote machines are often AIX or HP-UX servers…
Right, which is another reason why it would be unreasonable just to drop EWMH and go with D-Bus.
Using D-BUS as an alternate communication channel between window managers and other clients seems like it’d bring some tricky synchronization issues. What happens if a message that a client sends about a window via D-BUS arrives at the WM before the window’s CreateNotify event?