Patch pushed to git, closing task.

Close from commit: d5d4ae7cdd0517b6fa399c1dfdbf81eb0bd08f8d by Andreas

Now it works for me as expected. Thanks.

The EWMH specifies that the property should be removed when the window gets withdrawn. Well, I haven't considered psi to be a legacy application yet, but we should do it anyway.

Please try the new patch but beware as I haven't tested it.

Well, as a parent for the window is found the initial _NET_WM_DESKTOP should be ignored shouldn't it? I need to re-read the specs, but does this happen with other window managers?

I think that psi requests the chat windows to be opened at a specific workspace (_NET_WM_DESKTOP), therefore atm I consider this a bug/misfeature of psi.

I'll need to take a second look at this before I can say if it looks correct or not. However, civ notes that this causes the window not to be mapped on the current workspace.

Maybe, we should move the parent frame to current workspace and show it if the client being mapped is active? (Just an idea, not really validated yet... ;) )

Now the window works fine. But I think, the desired behaviour would be opening the window on the current workspace. (That's the whole point of using keyboard shortcut for incoming chat message :-) Now it's somehow locked to the workspace, where it was opened for the first time.

Thank you, now I can reproduce it. Please test the attached patch for any regressions and if it really fixes the bug for you, too. Thanks in advance. :)

Pekdon, do you think this is correct?

I open the chat window usually via a keyboard shortcut (Configuration is in Menu/Options/Advanced/Options/Shortcuts/Global), but the same thing happens, when you send Psi's main window to a different workspace and there you open the chat window.

How do you open it on a different workspace? Here it keeps opening on the first workspace. And it responds just fine.

Might this be related to systray icon/uniconifying of Skype windows which seem to behave in a similar fashion?