From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901
Description of problem:
Sawfish's matched windows whose initial state is "iconified, sticky,
sticky-viewport" can be be uniconfiable after certain iconification actions.
Iconifying using the task list buttons does NOT bring on the bug. Iconifying by
the window frame button or by key-board shortcuts DOES bring it on.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Set up your desktop for multiple virtual desktops with multiple viewports.
(I use 6 desktops with 3x2 viewports each, but I've seen this behavior with fewer.)
2. Launch a window-spawning application, say, the Gnome calendar.
3. Use Sawfish's matched window control to add an entry. Go to the "state" tab
and check the boxes for iconified, sticky and sticky-viewport. Set the match
type to name and grab the name of the calendar window.
4. Close the calendar application, relaunch it, and deiconify the calendar
window by clicking on its tasklist button.
5. Iconify the calendar window using the window button (NOT the tasklist
button). Go to a different viewport on a different virtual desktop and
deiconify it using the tasklist button.
6. Repeat 5 until you can nolonger deiconify the calendar.
Actual Results: After a number of repetitions of step 5 above, the window can
no longer be deiconified. The required number of steps varies. Sometimes,
trying to do this on purpose does not work. I have to work a bit and come back
to it. The fastest I've been able to bring about the bug is after about 4
times. Sometimes, it never happens while I try to make it happen.
Expected Results: You should always be able to deiconify the window by using
the tasklist button, no matter how that window was iconified.
This behavior is erratic. It's been happening for as long as I've been using
Sawfish (which I think is a great wm, by the way), which has been several RH
releases ago. But its unpredictable behavior made me dread trying to write a
I think this is a sawfish bug, but I suppose it could be due to another
component of the Gnome desktop.
I've reported this upstream as
Closing on the Red Hat level.