This post is a presentation of the ideas behind GNOME bug 521914.

At present, we ship a program called metacity-dialog, which is often to be found as the sole occupant of /usr/lib/metacity, and it gets spawned on the rare occasions when Metacity needs to ask the user a question. For example, if you attempt to close a window, Metacity asks the permission of the program which owns it; if nothing is heard back from that program within a reasonable time, Metacity spawns metacity-dialog to ask the user whether the window should be closed by force.

There are only three occasions when Metacity needs to ask such questions, and metacity-dialog has ad hoc code for each, with the usual problems attendant on ad hoc code. When there’s any difficulty with metacity-dialog (see, for example, Debian bug 427406), reproducing the fault can be pretty difficult.

GNOME also includes another program called zenity, whose purpose is to pop up and ask questions in just this way. Zenity is stable, polished, and well-understood. With the closing of GNOME bug 335763, zenity’s abilities are now a superset of metacity-dialog’s. It would be a simple matter to remove metacity-dialog from the codebase, and use zenity instead.

The only difficulty I can see is that in some distros it may not always be true that if Metacity is installed, zenity will be too, and it may be difficult to add this as a dependency. Of course, they can always patch and keep metacity-dialog; what do you folks think?

Photo by Dave Spellman; cc-by-nc.

Published by

Thomas Thurman

Mostly themes, triaging, and patch review.

4 thoughts on “Zenity”

  1. Personally, i think replacing metacity-dialog with Zenity would be a good idea. It gives metacity a slimmer code-base and it kind of goes moreso with the *nix ideals of “shared libraries” wherein if there’s a library or another piece of code that does what you need, why write your own code?

    Also, Zenity is included in the GNOME base install on almost every distro i’ve tried in the past few years (Fedora, Debian, Ubuntu, Arch, Gentoo, etc). As a side option, you could have the Zenity code in a current .c file and have the metacity-dialog code in a separate .c file where if it can’t find Zenity, it falls back to metacity-dialog.

  2. Making metacity depend on zenity is a good idea after all: zenity isnt much trouble, and in the end, its very useful to install anyway. People would use zenity a lot more if metacity starts making use of it.

  3. I agree with JD that you should have a soft dependency on zenity because it might not always be available. But it should be at least encouraged by being used by default. The built in metacity-dialog code should be bare minimal GTK code that is only invoked as a fall back measure. Or else I think it maybe best to just make zenity a hard decency.

Leave a Reply

Your email address will not be published. Required fields are marked *

Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported.