zinnia

Zinnia é um front-end gráfico para manipulação de arquivos 7-Zip, construído com Tauri e distribuído para Windows, macOS e Linux. O README o apresenta como um compactador de desktop operado por meio de uma GUI nativa em vez da linha de comando, com foco em empacotamento e instaladores para tornar as operações de arquivo acessíveis a partir do próprio sistema operacional. O suporte de plataforma declarado no README é: macOS 26 ou posterior, com uma build universal abrangendo máquinas Intel e Apple silicon capazes de executar essa versão; Windows 10 versão 2004 (build 19041) ou posterior em x64 ou ARM64; e Linux x64 no Ubuntu 24.04+, Debian 13+ ou Fedora 43+ (ou uma distribuição compatível com o runtime WebKitGTK necessário). Os lançamentos públicos de Linux fornecem pacotes AppImage, DEB, RPM e Flatpak sideloaded em x64, enquanto AppImage/DEB/RPM em ARM64 são publicados apenas quando explicitamente construídos para um lançamento, e o Flatpak permanece em x64. Um foco notável é a integração com o sistema operacional. As builds empacotadas registram tipos comuns de arquivos de arquivo. No Windows, as builds NSIS adicionam verbos do Explorer por usuário para "Abrir com Zinnia", "Extrair com Zinnia" e "Comprimir com Zinnia" como um fallback clássico, incluindo o caminho através de "Mostrar mais opções" do Explorer. Builds NSIS assinadas para Windows registram adicionalmente um menu de contexto moderno do Windows 11 por meio de um MSIX de identidade esparsa mais uma zinnia_shell.dll, fornecendo um submenu Zinnia e uma entrada de Extração de nível superior em arquivos; assim que o registro moderno for bem-sucedido, os verbos clássicos são removidos para evitar empilhamento, permanecendo como fallback se o registro do pacote falhar. O README observa que o Zinnia permanece como uma instalação Win32 NSIS normal por usuário e que o MSIX não é um pacote de aplicativo Store/AppX, mas apenas concede identidade de pacote para que o Explorer possa carregar a DLL do shell. No Linux, os pacotes deb, rpm e Flatpak incluem ações de Abrir, Extrair e Comprimir na área de trabalho. No macOS, os usuários podem escolher o Zinnia através do fluxo de app padrão "Abrir Com/Obter Informações" do Finder, e as inicializações de arquivos são roteadas para uma janela de extração rápida. As builds empacotadas também expõem itens de menu de contexto do Finder Sync e Serviços do Finder para "Extrair com Zinnia" e "Comprimir com Zinnia"; o Finder Sync monitora apenas Desktop, Documentos, Downloads, Filmes, Música, Imagens e volumes montados no momento, sendo os Serviços do Finder sugeridos para arquivos em outros locais. As instruções de desenvolvimento são convencionais para um projeto Tauri: npm install, npm run tauri:dev e cargo doc contra src-tauri/Cargo.toml. Comandos diretos do Cargo funcionam sem uma etapa de preparação separada porque o script de build do Tauri atualiza os binários sidecar ignorados a partir de assets rastreados antes da execução da build nativa. Os scripts de build são nomeados por plataforma: build:win, build:mac:universal seguido por build:mac:zip, build:linux (ou build:linux:x64), build:linux:arm64 para ambientes ARM64 nativos e flatpak:bundle. A assinatura de lançamentos está disponível através de um script GPG. O README também documenta o processo de atualização e lançamento em detalhes: o atualizador é configurado em src-tauri/tauri.conf.json; a CI executa testes e verificações no Linux, Windows e macOS, mas nunca constrói binários de lançamento, publica lançamentos ou consome segredos de assinatura de lançamento. Lançamentos assinados são deliberadamente explícitos, com scripts de lançamento específicos de plataforma organizando manifestos de atualização, artefatos, arquivos de checksum e assinaturas destacadas em um rascunho de lançamento do GitHub para a mesma versão. Scripts de continuação beta sincronizam automaticamente os manifestos beta de uma VM no feed de lançamento estável mais recente, inclusive enquanto uma tag ainda é um rascunho, pois clientes beta consultam o feed ao vivo; existe um script de sincronização separado para recuperação. Etapas de verificação são fornecidas para rascunhos e lançamentos publicados, verificando a matriz de alvos esperada, versão e assinaturas e checksums de artefatos do atualizador. Orientações são incluídas sobre como lidar com identificadores temporários de rascunhos não tagueados do GitHub, sobre a retomada de uma sessão de preparação de lançamento existente vinculada a um commit, lockfiles, plataforma, arquitetura e toolchain específicos, e sobre scripts de propagação de versão que copiam a versão do pacote para manifestos nativos, URLs de download de changelog e metadados AppStream. O README encerra alertando contra o envio de uma tag de lançamento antes que cada artefato de plataforma esteja presente e sua assinatura e checksum do atualizador sejam verificados. Documentação adicional do projeto é referenciada através de ARCHITECTURE.md, CONTRIBUTING.md e SECURITY.md, juntamente com notas de shell do Windows e menu de contexto de QA no repositório.