Re: Window Maker bug or feature?

SL Baur writes: sb> If I have two XEmacs frames on a virtual desktop, double click on one of sb> the title bars so that only the title bar is showing, I cannot then make sb> the other XEmacs frame go away with `C-x 5 0'. It beeps and says that I am sb> attempting to delete the only visible or uniconified frame. ^^ I guess you means the only visible or iconified frame. sb> Is a title bar-only window then considered iconified? No, but anyway, icons are considered to be "visible frames" in the XEmacs sense, since you can access them back. The situation you describe is not due to a WindowMaker bug (at most a misconception), but rather is a typical example of the lack of communication between applications and their window manager. Let me explain: X windows can have three states: /normal/ (they're displayed on the screen), /iconified/ (you have a small window provided by the window manager in place of the real window), and /withdrawn/. In this last state, a window and all its children are unmapped; they're not visible, neither have an icon, but still do exist logically and are managed by the server. This state is particularily usefull when you have to compute a complex widget geometry, leading to annoying visual changes on the interface. You can do that in the withdrawn state and map the window afterwards. To determine whether a frame is potentially visible, XEmacs finds all frames whose widgets are either in normal state, or iconified. I suppose that WindowMaker implements the `shade' feature by putting the frame in withdrawn state. Consequently, this frame will be seen as invisible by XEmacs. It is logical that withdrawn frames are not counted as "visible" by XEmacs. The problem here is that XEmacs would have to communicate with the window manager in order to realize that even if this frame is withdrawn, the user can get it back with a wm command, and so it should be counted as visible. I can be wrong but I'm pretty sure however that WindowMaker doesn't provide such a complete WM communication protocol for its clients. Another question which remains unasked: is it possible that at a time of a delete frame request, another one can be withdrawn with no possible way of getting it back? I don't know ... -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 73 46 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19