This behaviour appears when using empathy and trying to iconify the contact list. See http://bugzilla.gnome.org/show_bug.cgi?id=541154 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=491817 The patch to empathy which solves this problem looks like : gtk_window_iconify (window); + gtk_widget_hide (GTK_WIDGET (window)); but it has been rejected, since calling gtk_window_iconify should (?) hide the window, as metacity and others do. I did not find a bug related to this here, please correct me if i'm wrong.
Created attachment 1858 Sample program Works for me, gtk_window_iconify () does hide the window. See attached sample code. Tested on both branches 4.4 and trunk (4.6)
Oh, but I know why! Look at the empathy code: gtk_window_set_skip_taskbar_hint (window, TRUE); gtk_window_iconify (window); xfwm4 will refuse to iconify a window if skip_taskbar is set because the user may not be able to restore it (iconify != hide) This is a bug in the application IMHO.
indeed no bug using your test app. I fully understand the reason why you forbid minimization when skip_taskbar is set. This matches the semantics of minimization :))) I just wonder what to do to get rid of that bug : convince empathy developers or xfce developers ? see http://bugzilla.gnome.org/show_bug.cgi?id=541154#c3 i guess he prefers every wm patches instead of he patches one app :(
(In reply to comment #3) > indeed no bug using your test app. > [...] > http://bugzilla.gnome.org/show_bug.cgi?id=541154#c3 > > i guess he prefers every wm patches instead of he patches one app :( There is a confusion between iconification and withdrawal of windows. It's the role of the window manager to decide if iconification is suited. This application depends on a particular implementation of the WM, and this is not correct.
Switching the two calls was the solution... gtk_window_iconify (window); gtk_window_set_skip_taskbar_hint (window, TRUE); please don't be malicious and don't add extra checks, like forbid to hide taskbar_hint when window is already minimized :)
Hello, I'm Empathy's maintainer. So if xfwm4 wasn't buggy it should refuse the skip taskbar hint if iconified. Invert that 2 lines shouldn't change anything. And probably xfwm4 will make it fail now that bug is discovered. Now I understand why rhythmbox calls gtk_widget_hide() on the window after gtk_window_iconify, which is *explicitely* said as useless in GTK's API doc: Some WM refuse to skip taskbar hint so the only hack is to hide the window... Which is in fact another bug of xfwm4 that should refuse to hide a window when iconified. IMHO xfwm4 should not make such desision, the WM does not know if the application gives other ways to show the window again when it's iconified and skipped from taskbar. Obviously all applications that iconify in the tray does that. It is not just empathy that need to be patched, but *all* applications that iconify to the tray have hacks and workarounds for each WM that does different things.
(In reply to comment #6) > So if xfwm4 wasn't buggy it should refuse the skip taskbar hint if iconified. > Invert that 2 lines shouldn't change anything. And probably xfwm4 will make it > fail now that bug is discovered. No, I am not planning to add such a test case. Actually I am planning to loosen the rule so that if the application itself requests the state change, then xfwm4 will honor it. Still, I disagree with the points below enumerated below. > Now I understand why rhythmbox calls gtk_widget_hide() on the window after > gtk_window_iconify, which is *explicitely* said as useless in GTK's API doc: > Some WM refuse to skip taskbar hint so the only hack is to hide the window... > Which is in fact another bug of xfwm4 that should refuse to hide a window when > iconified. Oh, you seem confused here unless I misunderstand your statement, of course an application can hide (ie unmap) a window when iconified. I don't understand you point, again iconify is not hide. And there is even an ICCCM mechanism specifically for that. > IMHO xfwm4 should not make such desision, the WM does not know if the > application gives other ways to show the window again when it's iconified and > skipped from taskbar. Obviously all applications that iconify in the tray does > that. Iconify to systray is nonsense inherited from Windows wanabees. Iconfication is a state, you don't iconify to something. BTW the issue is not here, the window manager can decide of any operation done on a window, like if a window can be iconified or not, it is its role (among a lot of others). > It is not just empathy that need to be patched, but *all* applications that > iconify to the tray have hacks and workarounds for each WM that does different > things. Welcome to the world of X11, but IMHO that's what make X11 a much more interesting platform. If you want only one behavior, create a standard, if you want only one implementation, use a platform with only one window manager such as Windows.
Committed in rev. 28011. http://svn.xfce.org/index.cgi/xfce/diff/xfwm4/trunk/src/events.c?rev1=28010;rev2=28011 For xfce 4.6 only. I do not plan to backport this to the xfce 4.4 branch though to avoid a change in behavior in the middle of stable release.
Well actually, also committed to 4.4 branch so we have a consistent behavior.