zinnia

Zinnia es un front-end gráfico para el manejo de archivos 7-Zip, construido con Tauri y distribuido para Windows, macOS y Linux. El README lo presenta como un archivador de escritorio impulsado por una GUI nativa en lugar de la línea de comandos, con un trabajo de empaquetado e instalador orientado a hacer que las operaciones de archivo sean accesibles desde el propio sistema operativo. El soporte de plataforma indicado en el README es: macOS 26 o posterior, con una compilación universal que cubre máquinas Intel y Apple silicon capaces de ejecutar esa versión; Windows 10 versión 2004 (build 19041) o posterior en x64 o ARM64; y Linux x64 en Ubuntu 24.04+, Debian 13+ o Fedora 43+ (o una distribución compatible con el runtime WebKitGTK requerido). Las versiones públicas de Linux incluyen paquetes x64 AppImage, DEB, RPM y bundles Flatpak cargados lateralmente, mientras que los AppImage/DEB/RPM de ARM64 se publican solo cuando se compilan explícitamente para un lanzamiento y Flatpak permanece en x64. Un enfoque notable es la integración con el sistema operativo. Las compilaciones empaquetadas registran tipos de archivos de archivo comunes. En Windows, las compilaciones NSIS agregan verbos de Explorer por usuario para "Open with Zinnia", "Extract with Zinnia" y "Compress with Zinnia" como un respaldo clásico, incluyendo la ruta a través de "Show more options" de Explorer. Las compilaciones NSIS de Windows firmadas registran además un menú contextual moderno de Windows 11 a través de un MSIX de identidad dispersa más un zinnia_shell.dll, proporcionando un submenú de Zinnia y una entrada de Extract de nivel superior en los archivos; una vez que el registro moderno tiene éxito, los verbos clásicos se eliminan para evitar la duplicidad, y permanecen como respaldo si el registro del paquete falla. El README señala que Zinnia sigue siendo una instalación normal de NSIS Win32 por usuario y que el MSIX no es un paquete de aplicación Store/AppX, sino que solo otorga identidad de paquete para que Explorer pueda cargar la DLL del shell. En Linux, los bundles deb, rpm y Flatpak incluyen acciones de escritorio de Open, Extract y Compress. En macOS, los usuarios pueden elegir Zinnia a través del flujo de aplicación predeterminada Open With/Get Info de Finder, y los lanzamientos de archivos se redirigen a una ventana de extracción rápida. Las compilaciones empaquetadas también exponen elementos del menú contextual de Finder Sync y Servicios de Finder para "Extract with Zinnia" y "Compress with Zinnia"; Finder Sync solo monitorea Desktop, Documents, Downloads, Movies, Music, Pictures y los volúmenes montados actualmente, sugiriéndose los Servicios de Finder para archivos en otras ubicaciones. Las instrucciones de desarrollo son convencionales para un proyecto Tauri: npm install, npm run tauri:dev, y cargo doc contra src-tauri/Cargo.toml. Los comandos directos de Cargo funcionan sin un paso de preparación separado porque el script de compilación de Tauri actualiza los binarios sidecar ignorados a partir de los activos rastreados antes de que se ejecute la compilación nativa. Los scripts de compilación están nombrados por plataforma: build:win, build:mac:universal seguido de build:mac:zip, build:linux (o build:linux:x64), build:linux:arm64 para entornos ARM64 nativos, y flatpak:bundle. La firma de lanzamientos está disponible a través de un script GPG. El README también documenta el proceso de actualización y lanzamiento con cierto detalle: el actualizador está configurado en src-tauri/tauri.conf.json; la CI ejecuta pruebas y verificaciones en Linux, Windows y macOS, pero nunca compila binarios de lanzamiento, publica lanzamientos ni consume secretos de firma de lanzamiento. Los lanzamientos firmados son deliberadamente explícitos, con scripts de lanzamiento específicos de la plataforma que organizan manifiestos del actualizador, artefactos, archivos de suma de comprobación y firmas adjuntas en un lanzamiento borrador de GitHub para la misma versión. Los scripts de continuación de beta sincronizan automáticamente los manifiestos beta de una VM en el feed de lanzamiento estable más reciente, incluso mientras una etiqueta es todavía un borrador, porque los clientes beta consultan el feed en vivo; existe un script de sincronización separado para la recuperación. Se proporcionan pasos de verificación para borradores y lanzamientos publicados, comprobando la matriz de objetivos esperada, la versión y las firmas y sumas de comprobación de los artefactos del actualizador. Se incluye orientación sobre el manejo de los identificadores temporales de borradores sin etiqueta de GitHub, sobre la reanudación de una sesión de preparación de lanzamiento existente vinculada a un commit, lockfiles, plataforma, arquitectura y toolchain específicos, y sobre los scripts de propagación de versiones que copian la versión del paquete en los manifiestos nativos, URLs de descarga del changelog y metadatos de AppStream. El README cierra advirtiendo contra el envío de una etiqueta de lanzamiento antes de que esté presente cada artefacto de plataforma y se haya verificado su firma y suma de comprobación del actualizador. Se hace referencia a documentación adicional del proyecto a través de ARCHITECTURE.md, CONTRIBUTING.md y SECURITY.md, junto con notas sobre el shell de Windows y el menú contextual de QA en el repositorio.