Saltar al contenido

Cerrar una ventana frente a salir

Las dos acciones que el usuario confunde y el sistema distingue, con reglas distintas en cada plataforma. Cómo se interceptan, y el diálogo de cambios sin guardar bien hecho.

Qué hace cada plataforma

Respetar la convención de cada uno es lo correcto, aunque signifique comportamientos distintos. Forzar que cerrar sea salir en macOS es tan raro como forzar lo contrario en Windows.

La excepción es la aplicación de bandeja del nivel 7.2, donde cerrar esconde en las tres plataformas y salir es una acción explícita del menú de la bandeja. Eso también es coherente porque el usuario ya sabe que la aplicación vive ahí.

Interceptar

Las dos acciones se interceptan en el manejador del nivel 25.2, y las dos se pueden impedir:

Rust
.run(|app, evento| match evento {    // una ventana concreta va a cerrarse    tauri::RunEvent::WindowEvent {        label,        event: tauri::WindowEvent::CloseRequested { api, .. },        ..    } => {        if hay_cambios_sin_guardar(app, &label) {            api.prevent_close();          // de momento no se cierra            preguntar_y_decidir(app, &label);   // y se decide en otro sitio        }    }    // la aplicación va a terminar    tauri::RunEvent::ExitRequested { api, .. } => {        if algun_trabajo_pendiente(app) {            api.prevent_exit();        }    }    _ => {}});

La clave está en las dos últimas líneas del primer bloque: impedir el cierre y decidir aparte. Preguntar dentro del manejador significaría bloquear el bucle mientras el usuario piensa, que es el caso 5 del nivel 24.3.

El diálogo, sin bloquear

El patrón correcto tiene tres pasos y no bloquea nunca:

El paso 3 tiene una trampa: cerrar la ventana desde el código vuelve a disparar el evento de petición de cierre, así que si la condición sigue siendo cierta se entra en bucle. La corrección es marcar esa ventana como «ya confirmada» antes de cerrarla, y que la condición lo compruebe.

Varias ventanas con cambios

El caso que rompe las implementaciones ingenuas: el usuario sale de la aplicación y hay tres ventanas con trabajo sin guardar. Tres opciones:

  • Preguntar por cada una, en orden. Es lo que hacen los editores, y hay que enfocar cada ventana antes de preguntar para que el usuario sepa de cuál se trata.
  • Un solo diálogo con la lista. «Hay cambios sin guardar en 3 documentos», con guardar todo, descartar todo, o cancelar. Más rápido y menos preciso.
  • Guardar todo automáticamente y no preguntar. La mejor si tu aplicación puede: si el guardado es continuo —la política del nivel 22.5— este problema no existe.

La tercera merece señalarse porque elimina el nivel entero. Una aplicación que guarda mientras el usuario escribe no tiene que preguntar nada al cerrar, y es una de esas decisiones que simplifican mucho más de lo que cuestan.