Anatomía de un fichero de capability
Los seis campos de un fichero de capability, qué decide cada uno, y los valores por defecto que hay que conocer porque conceden más de lo que parece.
El fichero
{ "$schema": "../gen/schemas/desktop-schema.json", "identifier": "proyectos", "description": "Lo que la ventana principal necesita para trabajar con proyectos", "windows": ["main"], "platforms": ["macOS", "windows", "linux"], "local": true, "permissions": [ "core:default", "dialog:allow-open", { "identifier": "fs:allow-read", "allow": [{ "path": "$APPDATA/proyectos/**" }] } ]}Los seis campos
Los dos que hay que poner siempre
windows. Es el campo que convierte el modelo nuevo en algo distinto de la lista blanca del nivel 27.2. Sin él, una capability aplica a todo, incluida la ventana que abras mañana para mostrar algo que no controlas.
La regla: nombrar siempre las ventanas, aunque hoy solo haya una. Cuesta una línea y evita que una ventana futura herede permisos sin que nadie lo decida.
description. No hace nada funcional y es la respuesta a la pregunta del nivel 26.5 —«¿por qué está esto?»— dentro del propio fichero. Una descripción que diga el porqué convierte la revisión en lectura.
// mal: dice lo que ya se ve"description": "Permisos de diálogo y ficheros"// bien: dice por qué existe"description": "La ventana principal abre proyectos que el usuario elige por el diálogo del sistema y los lee del directorio de datos"Ventanas y webviews
Un matiz que aparece en cuanto hay varias webviews en una ventana —nivel 12.2—: además de windows hay un campo para nombrar webviews concretas, y en el caso normal —una webview por ventana— los dos hacen lo mismo.
La regla práctica: usa windows salvo que tengas varias webviews en una ventana, y si las tienes, ahí es donde el reparto fino importa de verdad — porque el caso de uso de varias webviews es precisamente aislar contenido ajeno, y darle a esa webview lo mismo que a la tuya anula el ejercicio.
El esquema
La primera línea del ejemplo apunta a un esquema generado, y merece ponerla por lo mismo que el del nivel 8.5: el editor autocompleta los identificadores de permiso disponibles.
Eso convierte el problema de «qué permiso necesito» en una lista desplegable, y es la forma más rápida de descubrir que existe uno más estrecho que el que ibas a poner. El esquema lo genera build.rs en el directorio de generados, así que aparece después de la primera compilación.