After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 521914 - Get rid of metacity-dialog and use zenity
Get rid of metacity-dialog and use zenity
Status: RESOLVED FIXED
Product: metacity
Classification: Other
Component: general
trunk
Other Linux
: Normal enhancement
: ---
Assigned To: Metacity maintainers list
Metacity maintainers list
Depends on: 335763 352298
Blocks:
 
 
Reported: 2008-03-12 03:30 UTC by Thomas Thurman
Modified: 2009-02-20 21:35 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Thomas Thurman 2008-03-12 03:30:17 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?
Comment 1 Thomas Thurman 2008-03-12 21:03:01 UTC
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
Comment 2 Elijah Newren 2008-03-13 00:34:39 UTC
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.
Comment 3 Thomas Thurman 2008-03-13 01:18:49 UTC
(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.

Comment 4 Thomas Thurman 2008-03-29 21:27:23 UTC
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. :) )
Comment 5 Havoc Pennington 2008-03-31 04:04:59 UTC
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.
Comment 6 Alexander “weej” Jones 2008-04-07 01:26:15 UTC
Can't metacity create its own windows rather than relying on other processes? Surely that would be more efficient.
Comment 7 Thomas Thurman 2008-04-07 01:36:44 UTC
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.
Comment 8 Thomas Thurman 2009-01-27 01:09:28 UTC
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.
Comment 9 Thomas Thurman 2009-02-20 21:35:27 UTC
Okay, all three are replaced, so this is FIXED.