Ten en cuenta además que los navegadores web incluso con cosas tan plásticas como el firefox, que permite una programación muy detallada con
XUL, quizás no permita una personalización tan grande como lo pueda permitir un gestor de ventanas moderno.
Yo pienso que quizás el problema es de diseño.
Me explico: tenemos que aceptar la idea de que un usuario puede desear terminar el proceso cerrando la ventana. Digo cerrar y no terminar. Algo que es común a todos los gestores de ventanas es dar la posibilidad al usuario de que cierre todas las ventanas (incluídas las cajas de alerta). Es luego responsabilidad de la aplicación qué hacer cuando se recibe el evento de que el usuario desea cerrar la ventana.
En las cajas de alerta, si se ofrece al usuario varias opciones, cerrar la ventana equivale casi siempre a pulsar el botón Cancelar. Si sólo hay un botón, equivale al de Aceptar. En esos casos es claro y fácil trasladar el deseo del usuario de cerrar la ventana a una de las operaciones que se le ofrecián dentro del formulario o caja de alerta.
Pero, ¿qué pasa en el resto de formularios? Pues que se considera que el usuario Cancela el formulario. ¿Y qué pasa en los formularios que siguen una serie de pasos guiados a lo largo de un procedimiento? Por ejemplo, en el proceso de compra en una página web, al usuario se le lleva por una serie de páginas/formularios para que los rellene con sus datos.
Bueno, pues en todos y cada uno de esos diálogos hay que plantearse el caso de que el usuario puede desear Cancelar la operación, es decir, NO terminar, sino abortar. Pues entonces, dentro de nuestro programa, debemos prever esas situaciones y responder adecuadamente.
No sabemos porqué ha decidido no terminar la operación, y no es cosa nuestra saberlo. Si luego, el usuario piensa que la operación es importante, volverá a entrar y seguirlo. Nuestra responsabilidad acaba al hacer un programa sin fallos (ojalá) y una formación al usuario para que sepa manejarlo (un cursillo o unos párrafos explicativos de lo que tiene que hacer).