>> Andy> AddToFunc WindowOps-or-Kill "M" Menu Window-Ops2 Nop
>> Andy> + "C" Menu Window-Ops2 Nop
>> Andy> + "D" Delete
>> Andy> + "D" Close
>> Andy> + "D" Destroy
>>
>> Andy> What I thought this would do when I double click is this:
>> Andy> 1.) try to Delete the window
>> Andy> 2.) if 1.) failed try to Close the window
>> Andy> 3.) if 2.) failed also, Destroy the window.
>>
>> Andy> But what happens is that the window always gets destroyed.
>> Andy> Is this a bug or a feature? If it's a feature would it be
>> Andy> possible to make this behavior optional?
>
>The way I understand it, it should be very easy, since fvwm1 did do this
>already. On the other hand there may be many internal changes that I am
>not aware of that make it impossible to port the v1 code to fvwm2.
>Is that the case?
Here's how it goes:
>> Andy> + "D" Delete
Fvwm checks to see if the window understands the "Delete" protocol. Not all
windows do. If it understands "Delete", fvwm sends the delete message
to the window. If the program operating the window is working well, it
will remove itself sometime in the relatively near future. (May not be
immediate, the application may pop-up a confirm box, may save its state,
whatever). As far as fvwm is concerned, the "Delete" action is done when
the message is sent, even if the window still exists.
> Andy> + "D" Close
Similar to delete, but if the window doesn't understand "Delete", the window
is destroyed. At this point, you have either sent two delete messages, or
have beeped and destroyed the window. When destroying a window, Fvwm
actually removes the window, and the program usually, but not always,
crashes.
> Andy> + "D" Destroy
This will make fvwm actually destroy the window. Chances are, this will
happen before any of the "Delete" messages are handled by the application.
While it would be nice for fvwm to send a delete message, and then wait
to see if the window goes away, and then destroy the window if its not
responding, this is difficult to code up. What if the program pops up
a confirm dialog before going away? The delay could be indefinite.
The correct thing to put in your menu, is a simple "Close" this will
correctly remove all windows, except those that understand "Delete" and
are misbehaving (crashing, poorly written, whatever). To handle the case
of a misbehaving window, have a separate item "Destroy" which you invoke only
if the window doesn't respond to "Close"
Rob
--
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Wed Dec 20 1995 - 09:28:37 GMT