Description of problem:
When debugged the script gnome-panel-test-starting-every-app.py in RHEL4-U3
system, sniff can't catch the 'Close Window' of applications.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. wrote script to quit application.
2. clicked 'Quit' or clicked 'Close' or clicked 'Cancel' to quit application.
3. if sniff can catch the 'Close Window' of each application, it would be easy
to quit the application.
can not catch the 'Close Window' signal
can catch the 'Close Window' signal
I'm not sure what you're asking for here. It looks like you want to be able to
know when a window is closed, but I'm not sure exactly why or how you would want
that to look in a script.
Created attachment 134764 [details]
This bug was a suggestion.
Sniff can't catch the 'Close Window' signal of 'title bar'.
For example, viewed the attachment of gnome-cd application:
Click 'Close Window' of 'title bar' of click 'Close' of 'Window menu' may quit
the application. But sniff can't catch both signals.
I see; the problem here is that metacity is not accessible. If it could expose
the right information, we would be able to use it. Reassigning to metacity.
Marking as low severity so Sören isn't too bothered by the bug staying open :)
This is really much much more likely to be fixed if filed upstream. I am almost
certainly not going to fix it downstream.
Are you really sure metacity is the right place to fix it? It sounds to me like
what is desired is a way to trigger the "delete_event" signal from inside
I don't expect you to fix it downstream :)
The reason it seems to make sense for metacity to have accessibility support is
that we could also really use things like being able to move windows around. If
we knew for sure where the decorator was, we could just send mouse events to
drag it. Also, eventually maximize et. al. would be nice.
But essentially everything interesting you can do to windows is already exposed
through libwnck. You can move/resize/maximize/close/etc. That's how the various
pagers and window menus work.
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.
If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)
Thanks for your help, and we apologize again that we haven't handled
these issues to this point.
The process we're following is outlined here:
We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
CANTFIXing this as it's an upstream problem...