On 21 Nov, Matthias Ettrich scribbled:
->  Hi, 
->  WM_DELETE_WINDOW is a nice WM protocol, but far from sufficient.
->  One of the standard questions of new X users is: "what to do with a program that
->  hangs and therefore doesn't close when I click on the close button?"
->  Overcoming this limitation is difficult. One solution is the fvwm way to
->  put the burden onto the user and to provide two entries "quit" and "close" in
->  the window operation menu (at least my old fvwm used to have this in its default
->  configuration). Disadvantage: the difference between quit and close is hard to
->  document and will hardly be understood by any normal user. And frankly, it's a
->  purely technical thing the interface should hide. 
->  The KDE way is to provide "quit" only, but offer a process manager and a
->  kill-window function in addition. But using these things requires at least
->  reading some documentation.
->  My suggestion is to add a new wm protocol, NET_WM_PING:
->  type = ClientMessage
->  window = client window
->  message_type = WM_PROTOCOLS
->  format = 32
->  data.l[0] = NET_WM_PING
->  data.l[1] = opaque handle set by the window manager to identify the ping
->  The client that recieves this message is obliged to send it back to the root
->  window immediatly ( set window=root and do a XSendEvent ).
->  With this protocol, the window manager has the possibility to issue a ping
->  right before sending the WM_DELETE message. If the reply doesn't arrive within
->  say 4 seconds it can display a message box: "The application doesn't react,
->  shall I kill it? [kill] [try again][cancel] "
->  Of course this procedures only works for clients that request the new wm
->  protocol, but that's better than nothing.

this would be good for detecting hung programs (tho sometiems it's ok
to have programs hang like this whislt running) but unless it's intded
foruse during normal runtime there isn't much point... the wm can do
this when the user hits "close" if the app doesnt respond and close its
widnow within N seconds (the wm knows then the app will close its
window) then the app can just go xkillclient.. even better.. i dotn
rememebr seeing anythgin abotu a hint to set process Id on the window
(and a manbdatory machine name hint - exists alreayd - but we shoudl
make it mandatory) then the WM can even issue a kill(pid, SIGKILL) if
this happens (of course this is all up tot he user to dictate what he
wants the wm to do for him) but it WOULD get rid of those rogue
netscapes i keep having hanging around that u have to kill the window
but the process still hangs around :)

--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler)

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]