GNOME Bugzilla – Bug 521914
Get rid of metacity-dialog and use zenity
Last modified: 2009-02-20 21:35:27 UTC
Really, doesn't everyone who ships Metacity ship zenity? Why are we maintaining a separate program? We currently have three cases, which are pretty closely: zenity --list --text "These windows do not support \"save current setup\" and will have to be restarted manually next time you log in." --column "Window" --column "Class" "Firefox" "foo" "Duke Nukem Forever" "foo" zenity --question --text "<big><b>Epiphany is not responding.</b></big>\n\n<i>You may choose to wait a short while for it to continue or force the application to quit entirely.</i>" zenity --error --text="There was an error running terminal:\n\nYour computer is on fire." It's not perfect (there's no way to set the buttons in the "not responding" instance to "Wait" and "Force Quit", nor a way to make the session dialogue time out), but zenity can always be patched. Meanwhile we have a few other places in the code where there are FIXMEs which would like to have a dialogue, but it would be so much extra work to add it to metacity-dialog that they don't bother. And we save build time and one extra program to go wrong. What do people think?
17:01 < lucasr> marnanel, zenity has timeout support 17:01 < lucasr> marnanel, it's just not shown in the dialog 17:02 < lucasr> marnanel, --timeout
I'm trying to think of reasons to not do this, and am coming up short (assuming the ability to set the button text to what we want gets fixed; there was more HIG work than you'd expect that went into those dialogs and we don't want it thrown out the window). Seems like a good idea to me.
(In reply to comment #2) > I'm trying to think of reasons to not do this The only problem I can think of is that we need to be sure that zenity's always installed, i.e. metacity gains a dependency on zenity. Do we have to tell everyone downstream about it, or can we assume that anyone installing GNOME will always have zenity installed? > (assuming the ability to set the button text to what we want gets fixed lucasr has since pointed out to me bug 335763, which contains a patch (under discussion, which has stalled a bit) to do just this.
I have rewritten the patch to meet the discussion there. Note also bug 352298; we'll need a way for zenity to make its dialogues appear on screen "n", which it appears not to have at present. (Easy answer is to reassign that bug to zenity. :) )
I don't remember the code at all, but the "force quit" dialog should be effectively transient for the window-to-be-quit and should go away when said window is closed. Just a couple regressions to avoid.
Can't metacity create its own windows rather than relying on other processes? Surely that would be more efficient.
There may be some more important reasons than these, but some reasons which come to mind are: 1) I don't want to have all the bother of dealing with handling our own windows specially in our main event loop; 2) Similarly it means that any errors which come up dealing with the user directly don't run the risk of segfaulting and bringing the whole WM down; 3) Zenity knows how to do this already and it will be trivial to ask it to; 4) Suppose someone wrote a program which killed the owner of a given window (Metacity itself knows how to do this for programs which don't respond to pings); blowing the WM away is counterproductive.
The environment variable WINDOWID, if set to the decimal representation of the X ID of an existing window, will cause Zenity to make new windows transient to that window.
Okay, all three are replaced, so this is FIXED.