GNOME Bugzilla – Bug 531512
Metacity integration with D-Bus
Last modified: 2011-08-11 10:30:05 UTC
As Metacity is the default window manager for the GNOME Desktop, and integrates perfectly with it, I believe that adding a D-Bus interface to Metacity is a mandatory step to bring this integration to the next level. Applications would connect to any window manager signal such as window getting focus, being minimized, maximized or restored, title changes, workspace switching; and a long etc. Also, applications could act over window manager behavior and perform tasks on current windows and workspaces. Jumping on D-Bus could open a new whole universe of possibilities for desktop applications to respond to and take control of the GUI. Some of the benefits that come to my mind right now are: - As desktop applications can detect if they have user's focus, we could have a per-application keyword layout setting, as in Windows, instead of the current desktop-wide setting. - Applications that block resources or use certain hardware devices could detect if they have no focus or they are minimized, and temporary free those resources and turn off the devices they use, in order to save energy. - On-line presence applications could detect switching on workspaces, to properly set their status to 'Away', like when locking the session. - Applications could modify their layout based on the geometry of the rest of the windows within a workspace. - It would be possible to make usage statistics for desktop applications, based on the time the application has been on user's focus. - Scripts that perform automated tasks on desktop applications, like GUI testers programs, could be greatly improved. I would love to hear your comments and ideas, and if anyone has already done something in that direction.
Created attachment 110402 [details] [review] Initial steps to get Metacity on D-Bus This patch adds a very basic D-Bus integration to Metacity. The main purpose of this initial work is to build a base library that is consistent and harmonic to Metacity code, and provide a solid foundation where further requirements and ideas can easily been integrated upon. Three files were added to 'src/core': - dbus.h - dbus.c - testdbus.c The first two provide a basic library to allow Metacity interaction with D-Bus, while the third is useful to test the integration. By now, the communication with the bus is unidirectional, only from Metacity to D-Bus (Metacity don't listen to any D-Bus signal, just publishes its own). Future development should provide bidirectional communication. Only 3 events are published to D-Bus: window focused, workspace switched and window title changed. More events shall be added when we have a stable base library. To test the patch: 1) Download the revision 3704 of Metacity package from its SVN repo. 2) Apply this patch. 3) Run './autogen.sh' and them 'make'. 4) If no errors, run 'src/metacity --replace &' to replace your current window manager (assuming you are using Metacity) by the patched one. 5) Run 'src/testdbus' to test it. The 3 Metacity events mentioned above should be logged out to your STDOUT. I hope this patch could be useful to start collaborating on this issue, or at least, start a debate on how to face the problem. Thank you in advance for your comments.
(In reply to comment #0) > Applications would > connect to any window manager signal such as window getting focus, being > minimized, maximized or restored, title changes, workspace switching; and a > long etc. Also, applications could act over window manager behavior and > perform tasks on current windows and workspaces. Applications can already do this using libwnck (or checking the various X messages from the EWMH directly). > Jumping on D-Bus could open a new whole universe of possibilities for desktop > applications to respond to and take control of the GUI. > Some of the benefits that come to my mind right now are: > - As desktop applications can detect if they have user's focus, we could have a > per-application keyword layout setting, as in Windows, instead of the current > desktop-wide setting. Applications can also just get FocusIn and FocusOut messages from X and use them to know whether they have focus...as reliably as possible anyway. No application (not even the window manager) can truly know which app has focus due to the way X works; it may have moved on without you having received notification yet. What does D-Bus buy us over x messages and libwnck?
Thanks for your comments Elijah. First I wanted to correct an idea in my first comment. > - As desktop applications can detect if they have user's focus, we could > have a per-application keyword layout setting, as in Windows, instead > of the current desktop-wide setting. I really meant that desktops can detect which application has focus, and have a keyboard layout setting in a per-app basis. I didn't know linwnck was used for this. I'm sorry, is my mistake. I will do a research about this library and see if I can find more solid reasons to implement D-Bus on Metacity. However after a quick glance, I found out that libwnck is unstable yet and has been for at least 3 years now (building progs spits a "libwnck should only be used if you understand that it's subject to frequent change, and is not supported as a fixed API/ABI or as part of the platform" if not compiled with -DWNCK_I_KNOW_THIS_IS_UNSTABLE). How fast/slow is its life-cycle, and when is expected to be a stable release? In the other hand, I personally don't like including and linking against an unstable library, gtk+, or X; just to access the window manager. I consider this should be done easier, and D-Bus is already there and was designed just for this kind of functionality. But this is just my humble opinion as new to Gnome. D-Bus is lightweight, fast, secure and reasonably extended so that programs and services can make extensible use of it. Applications could get simpler and lighter by just liking against D-Bus to access the world (the desktop), instead of linking against many libraries, each one with its own API, doc and manias). Many people (including me) envision a desktop fully tied up together with D-Bus. Maybe we could create a D-Bus based standard interface that all window managers provide, and programs just connect to this interface.
Hey Elijah :) Your question in comment #2 has been answered I guess. I'm thus reopening. Then I guess this issue is either to accept and set to NEW, or is set to WONTFIX, if you don't think this is a good idea. Also having the patch reviewed would be nice :) Eduardo, I suggest you to write an email to the metacity developers mailinglist and discuss this issue there.
I'm just worried that we'll export stuff over dbus and people will use it and it won't be portable to other WMs.
IMHO, a solid D-BUS interface for window managers can be designed and implemented, and we can encourage freedesktop.org to embrace it. It wouldn't necessarily break portability if the current interfaces (Libwnck and X events) are kept as an alternative to WMs on platforms not supporting D-BUS; and developers are advised about the compatibility issue. Tobias, thanks for your advise. I'll move the issue to the mailing list.
Review of attachment 110402 [details] [review]: Thanks for writing this, and many apologies for the delay in reviewing it. The patch no longer applies at all cleanly, unsurprisingly. If you're still interested in working on this, I think an appropriate thing to do if you come up with another patch is for us to commit it to a DBus-specific branch in git until it's closer to production quality. There did seem to be a lot of FIXMEs and TODOs in your patch. I would like DBus support to be turned on with an --enable-dbus switch to ./configure. I would like DBus support to be WM-independent. I don't want a repeat of the problem of tons of other WMs using Metacity's GConf settings and theme format.
This feature is no longer relevant I think, and as nobody else seems to be interested on it I'm closing this bug as obsolete. If someone yet thinks we should push some kind of D-Bus support in Metacity, please reopen the bug and I will be happy to help out. But I don't feel I have the interest nor the energy to push this right now.