Comment 2 for bug 787997

Revision history for this message
John Schember (user-none) wrote :

Putting down what I've found so far. This is mostly for me to keep track of what I've done with this issue as it's not going to be an easy fix.

First, window manager detection and specific work around are not going to be included. This is project policy.

Everything is in trayitem.cpp.

The issue is caused by function restoreWindow, line 128: XIconifyWindow(display, m_window, DefaultScreen(display));

With KWin this is causing a propertyChangeEvent of WM_STATE with the IconicState set. Line 326 is triggered which checks if a minimized window should be hidden. This happens after restoreWindow is has finished. The propertyChangeEvent does not happen with Metacity or Compiz.

The XIconifyWindow is required for multi-window applications (linked windows) such as audacious to have all of it's sub windows restored. Removing this would cause audacious to have it's sub-windows missing when restored.

Since the property change event happens after the restoreWindow function has finished a simple bool that says we are in a restore won't work because it will be set as having finished restoring at the end of restoreWindow so it won't ever be used. This is due to the property change event happening after restoreWindow finishes.

We can't do a skip next iconifyWindow variable because Metacity and Compiz do not send the property change event so this would cause the next time the user tries to hide the window to be ignored.

I did find that I need to add a second XMapWindow(display, m_window); call above the XRaiseWindow(display, m_window); on line 138. Otherwise the window may not be shown after restoring. It often stays minimized otherwise. This is related but only fixes part of the issue.

So I need to figure out a way to have the iconic state property change event to be ignored when it is caused by the XIconifyWindow in restoreWindow.

I have though of setting the time restoreWindow takes place and to ignore iconifyWindow calls that take place within a specific time interval. While not WM specific I would like to avoid this because it is very hackish and can fail in cases where the users computer slow or running slow.