zinnia

Zinnia est une interface graphique pour la gestion des archives 7-Zip, construite avec Tauri et distribuée pour Windows, macOS et Linux. Le README le présente comme un archiviste de bureau piloté par une interface graphique native plutôt que par la ligne de commande, avec un travail de packaging et d'installation visant à rendre les opérations d'archivage accessibles depuis le système d'exploitation lui-même. Le support des plateformes indiqué dans le README est le suivant : macOS 26 ou version ultérieure, avec une version universelle couvrant les machines Intel et Apple silicon capables d'exécuter cette version ; Windows 10 version 2004 (build 19041) ou ultérieure sur x64 ou ARM64 ; et Linux x64 sur Ubuntu 24.04+, Debian 13+ ou Fedora 43+ (ou une distribution compatible avec le runtime WebKitGTK requis). Les versions publiques Linux proposent des bundles AppImage, DEB, RPM x64 et Flatpak sideloaded, tandis que les versions AppImage/DEB/RPM ARM64 ne sont publiées que lorsqu'elles sont explicitement compilées pour une version, et que Flatpak reste en x64. Un accent notable est mis sur l'intégration au système d'exploitation. Les builds packagés enregistrent les types de fichiers d'archives courants. Sur Windows, les builds NSIS ajoutent des verbes Explorer par utilisateur pour « Open with Zinnia », « Extract with Zinnia » et « Compress with Zinnia » comme solution de repli classique, y compris via le menu « Afficher plus d'options » d'Explorer. Les builds NSIS Windows signés enregistrent additionally un menu contextuel moderne de Windows 11 via un MSIX à identité parcimonieuse plus une zinnia_shell.dll, offrant un sous-menu Zinnia et une entrée Extract de premier niveau sur les archives ; une fois l'enregistrement moderne réussi, les verbes classiques sont supprimés pour éviter l'empilement, et ils restent la solution de repli si l'enregistrement du package échoue. Le README précise que Zinnia reste une installation Win32 NSIS normale par utilisateur et que le MSIX n'est pas un package d'application Store/AppX mais accorde seulement une identité de package pour qu'Explorer puisse charger la DLL du shell. Sur Linux, les bundles deb, rpm et Flatpak incluent des actions d'ouverture, d'extraction et de compression sur le bureau. Sur macOS, les utilisateurs peuvent choisir Zinnia via le flux d'application par défaut « Ouvrir avec/Lire les informations » du Finder, et les lancements d'archives sont acheminés vers une fenêtre d'extraction rapide. Les builds packagés exposent également des éléments de menu contextuel Finder Sync et des services Finder pour « Extract with Zinnia » et « Compress with Zinnia » ; Finder Sync surveille uniquement le Bureau, Documents, Téléchargements, Films, Musique, Images et les volumes actuellement montés, les services Finder étant suggérés pour les fichiers situés ailleurs. Les instructions de développement sont conventionnelles pour un projet Tauri : npm install, npm run tauri:dev, et cargo doc contre src-tauri/Cargo.toml. Les commandes Cargo directes fonctionnent sans étape de préparation distincte car le script de build Tauri actualise les binaires sidecar ignorés à partir des assets suivis avant l'exécution du build natif. Les scripts de build sont nommés par plateforme : build:win, build:mac:universal suivi de build:mac:zip, build:linux (ou build:linux:x64), build:linux:arm64 pour les environnements ARM64 natifs, et flatpak:bundle. La signature des versions est disponible via un script GPG. Le README documente également le processus de mise à jour et de publication en détail : le programme de mise à jour est configuré dans src-tauri/tauri.conf.json ; la CI exécute des tests et des vérifications sur Linux, Windows et macOS mais ne compile jamais de binaires de production, ne publie pas de versions et ne consomme pas de secrets de signature de version. Les versions signées sont délibérément explicites, avec des scripts de publication spécifiques à la plateforme préparant les manifestes de mise à jour, les artefacts, les fichiers de checksum et les signatures détachées dans une version GitHub en brouillon pour la même version. Des scripts de continuation bêta synchronisent automatiquement les manifestes bêta d'une VM sur le flux de version stable le plus récent, même lorsqu'un tag est encore un brouillon, car les clients bêta interrogent le flux en direct ; un script de synchronisation distinct existe pour la récupération. Des étapes de vérification sont fournies pour les brouillons et les versions publiées, vérifiant la matrice cible attendue, la version et les signatures et checksums des artefacts de mise à jour. Des conseils sont inclus sur la gestion des identifiants de brouillon temporaires non tagués de GitHub, sur la reprise d'une session de préparation de version existante liée à un commit, des lockfiles, d'une plateforme, d'une architecture et d'une toolchain spécifiques, et sur les scripts de propagation de version qui copient la version du package dans les manifestes natifs, les URL de téléchargement du changelog et les métadonnées AppStream. Le README se termine par un avertissement contre le push d'un tag de version avant que chaque artefact de plateforme ne soit présent et que sa signature et son checksum de mise à jour ne soient vérifiés. Une documentation supplémentaire du projet est référencée via ARCHITECTURE.md, CONTRIBUTING.md et SECURITY.md, ainsi que des notes sur le shell Windows et le menu contextuel QA dans le dépôt.