Using the "shade" function of the xfce window manager causes our application to crash because the xfce does send UnmapNotify (in contrast to kwin). Background: Our application supervises ConfgureNotify events in order to preserve certain areas (status area with alarm boxes) from being covered. The window arrangement calls of our application (not being aware that the window is unmapped) leads to an endless recursion.
That's on purpose. The client window is *not* unmapped on shade, therefore, there is no unmap notify (btw, it's X that sends unmap notify, not the window manager). That's the main difference between iconification and shade. With shading, the window is still mapped and still accept focus. Please note that xfwm4 is not the only window manager to work like this and this is the correct expected behaviour.
Hi, thank you very much for your fast answer :-) My English ain't the best. Being busy to phrase the bug report I forgot one important info. :-( After "shading" the application receives ConfigureNotify events which we interpret to uncover the status area of our application (via XtVaSetValues). As result the shaded window (or better to say the remaining title) "jumps" to the top of the desktop. The window continues sending ConfigureNotify events with the original geometric values (which we in term we do interpret). This result in the described recursion which causes the application to fail. We had to disable the "status area cover protection" mechanism with this certain version of xfce. The code worked fine with mwm & kwin for over 10 years. Thanks again Helmut.
The client window is *not* unmapped when shaded in xfwm4, so no UnmapNotify should be sent. Your initial assumption that "arrangement calls of our application (not being aware that the window is unmapped) leads to an endless recursion." is therefore not correct. It seems you do not interpret the X events correctly and that leads to a crash in your application. You should monitor XVisibilityEvent instead of configure events (man XVisibilityEvent) and stop redrawing based on state "VisibilityFullyObscured". Try "xev", shade the window, and you'll get something like : VisibilityNotify event, serial 31, synthetic NO, window 0xa00001, state VisibilityFullyObscured Do an xwininfo on a shaded (or "rolled up") window and you'll see that the window is still mapped ("Map State: IsViewable") - You get no UnmapNotify simply because the window is not unmapped... It's still mapped, but not visible to the user. That's why you should monitor VisibilityNotify events. But I'm sorry, this is really not a bug in xfce.
I think I might understand your problem. Please tell me if I understand correctly, your application is trying to prevent the user from resizing the window so that some important parts of it become invisible (what you said by "status area with alarm boxes"). To do so, it monitors the configure events and reacts accordingly. Then it gets confused when shaded in xfwm4 because the window is not visible but still mapped. Reacting to configure notify enters an endless loop trying tho make the window visible while shaded? Humm, that's a design issue because an application should not try send a configure request when it receives a configure notify. That can lead to endless loops in many cases, along with race conditions problems and so on. The window manager always have the final word of window geometry (well, it's its job after all, manage windows). It does, however, obey some basic rules such as minimum size, base size, size increments, etc. So it would be much better and safer to specify a minimum size so that the window manager will prevent the user from resizing the window and thus hiding the important part of it. But that might not fit in the GUI design of your existing application. Another approach would be to monitor the _NET_WM_STATE atom and disable the window arrangement calls of your application when _NET_WM_STATE is _NET_WM_STATE_SHADED or _NET_WM_STATE_HIDDEN (it can be both) just like you do when the window is unmapped. This way, it (sh|w)ould work with all EWMH compliant window manager. _NET_WM_STATE is documented here: http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#id2507241 I hope this helps...
Ok, I've committed a change that *does* unmap the client window when shaded. That change should work although I liked the previous implementation better as it was a lot less intrusive in focus management. Let's see how this goes for now... You may want to try svn trunk revision 22806 or later. snapshot tar available here: http://www.foo-projects.org/~olivier/preview/xfwm4-4.3.90.2-r22806.tar.bz2
Ok, no major problem arise, so we'll keep things that way. That fixes the issue you reported.