Los eventos del bucle
El manejador que ve todo lo que le pasa a la aplicación: listo, una ventana hace algo, se pide salir, se sale. Qué llega por ahí, dónde se engancha, y por qué corre en el hilo principal.
Engancharlo
tauri::Builder::default() .setup(|app| { … Ok(()) }) .build(tauri::generate_context!()) // build en vez de run .expect("error al construir la aplicación") .run(|app, evento| match evento { // y aquí el manejador tauri::RunEvent::Ready => { … } tauri::RunEvent::WindowEvent { label, event, .. } => { … } tauri::RunEvent::ExitRequested { api, .. } => { … } tauri::RunEvent::Exit => { … } _ => {} });El cambio es build en lugar de run y después run con un bloque. La forma corta que se ha usado hasta ahora es azúcar para esto con un manejador vacío.
Qué llega
Corre en el hilo principal
Es la restricción del nivel y explica un fallo del catálogo del 24.3 —el caso 5—: el manejador es parte del bucle, así que todo el tiempo que pase dentro es tiempo en que la aplicación no atiende nada.
De ahí tres reglas:
- Nada de red, disco lento ni esperas dentro. Si el manejador tiene que hacer algo que tarde, lanza una tarea.
- Salvo al salir, donde hay que esperar de verdad y por eso el nivel 25.4 tiene su propio procedimiento.
- Y como está en el hilo principal, se puede tocar la interfaz directamente sin la función del nivel 24.2. Es una de las pocas ventajas de estar ahí.
Los dos sistemas de eventos, que no son el mismo
Merece la distinción explícita porque los nombres se parecen:
Y se conectan en un sitio: un evento del bucle se convierte a menudo en un evento del puente. La ventana va a cerrarse, el core lo recibe aquí, y avisa al frontend por el canal del nivel 20 para que guarde lo que tenga pendiente. Ese es el patrón del nivel 25.3.