Durvald
Player de música local-first com núcleo Rust compartilhado e interfaces nativas
Produto e estágio atual
Durvald é um player de música local-first em evolução de uma interface SolidJS/Tauri para aplicações nativas com núcleo compartilhado em Rust. O objetivo é organizar e reproduzir a coleção do usuário no próprio dispositivo.
A implementação macOS é a mais avançada. Windows faz parte da migração para interfaces nativas e Linux tem uma implementação GTK4 iniciada. Essas frentes estão em estágios diferentes; não há paridade de funcionalidades declarada entre as plataformas.
Versão nativa macOS: detalhe de álbum, lista de faixas e player persistente.
Autoria e aprendizado
Desenvolvi todo o projeto, do logotipo e da identidade visual às interfaces e ao núcleo Rust, com auxílio de diferentes modelos de inteligência artificial. Durvald é um projeto pessoal de desenvolvimento e aprendizado.
Da versão Tauri às interfaces nativas
A versão Tauri ainda estava incompleta, aproximadamente na metade do desenvolvimento, quando decidi privilegiar interfaces nativas como oportunidade de aprender SwiftUI e GTK4. Boa parte do núcleo Rust já era utilizada no Tauri; esse reaproveitamento limitou o impacto da mudança. A migração aconteceu durante a construção do produto, sem representar a substituição de um sistema consolidado em produção.
A primeira implementação combinou SolidJS na apresentação, comandos e eventos Tauri na comunicação e Rust no processamento. Seu código permanece público em durvald-tauri, como referência da etapa anterior do mesmo produto.
A arquitetura atual concentra as responsabilidades compartilhadas em durvald-core, independente de interface. A mudança preserva o objetivo do produto, mas substitui a camada de apresentação compartilhada por clientes nativos. Essa escolha exige manter integrações e comportamentos de interface por plataforma. A seção de memória registra uma observação local das duas versões; benchmarks controlados estão fora do escopo atual.
Captura da versão SolidJS/Tauri; não representa a interface nativa atual.
Consistência visual entre sistemas
A busca por interfaces próprias de cada sistema também respondeu a um problema observado pelo autor no Windows: efeitos de transparência e desfoque com backdrop-filter falhavam em componentes sobrepostos da interface Tauri. O autor relacionou esse comportamento à issue Chromium #40835530, fornecida como referência técnica da investigação.
Essa experiência aumentava o trabalho de compatibilidade visual da interface compartilhada e contribuiu para a decisão de adotar clientes nativos. A referência registra o problema investigado; o estado atual de resolução da issue não foi confirmado nesta revisão.
Captura do defeito no Windows fornecida pelo autor. O mesmo problema não era observado no Linux, segundo sua experiência.
Distribuição Linux e custo de manutenção
Além da busca por interfaces nativas, o fluxo Linux do projeto dependia de um ambiente Ubuntu, segundo a experiência do autor. Relatos externos contextualizam esse custo: a discussão #12960 registra uma falha de linuxdeploy no Arch após a compilação, com incompatibilidade da ferramenta strip e observações do mantenedor sobre portabilidade de glibc. As issues #15106 e #11701 também relatam falhas na geração de AppImage no Arch.
Esses relatos reforçam a necessidade de controlar o ambiente de empacotamento e as dependências de distribuição. Não demonstram uma exigência universal de Ubuntu nem uma comparação controlada entre distribuições. A migração para GTK4 retira a WebView do cliente Linux, mas não elimina a necessidade de validar bibliotecas de sistema, empacotamento e compatibilidade entre distribuições.
Núcleo compartilhado e contratos
O núcleo Rust concentra indexação da biblioteca, persistência SQLite, reprodução local, histórico, configurações e integração Last.fm. Clientes SwiftUI e outros consumidores FFI usam a superfície UniFFI; o cliente GTK4, também escrito em Rust, consome diretamente a API pública do núcleo, sem bindings UniFFI.
A separação mantém as regras compartilhadas fora das interfaces. A documentação define contratos para caminhos e capas gerenciadas, varredura e cancelamento, formatos de áudio e erros públicos. Os clientes devem reagir às variantes de CoreError, sem interpretar mensagens de diagnóstico como contratos.
Consistência e operações demoradas
Somente uma varredura da biblioteca pode ocorrer por vez. O cancelamento é cooperativo: o trabalho para nos pontos seguros e os resultados cancelados não são persistidos. Uma varredura completa reconcilia arquivos removidos; uma varredura parcial ou cancelada preserva os registros existentes.
No cliente GTK4, os widgets permanecem na thread GTK/GLib e as operações do núcleo são encaminhadas para um runtime Tokio. Essa divisão evita executar trabalho bloqueante na thread da interface e exige coordenar resultados assíncronos com o ciclo de vida da janela.
Implementação por plataforma
- macOS: cliente nativo SwiftUI com integração ao núcleo pela superfície UniFFI; frente mais avançada do desenvolvimento.
- Windows: frente em desenvolvimento na transição para uma implementação nativa. Este case ainda não oferece uma demonstração nem uma lista validada de funcionalidades dessa versão.
- Linux: base Rust/GTK4 que abre uma janela, inicializa o núcleo e consulta a quantidade de músicas persistidas. Importação, lista de faixas e controles de reprodução ainda são próximos passos. “Atualizar biblioteca” relê o banco; não inicia uma varredura.
Memória observada em idle
Em uma captura local do Activity Monitor, com as duas versões em idle segundo o autor, o processo da versão nativa (Durvald) apresenta 73,5 MB. Os quatro processos identificados pelo autor como pertencentes à versão Tauri somam 176,9 MB: http://localhost:1420 (95,7 MB), durvald (53,2 MB), durvald Graphics and Media (17,3 MB) e durvald Networking (10,7 MB).
| Implementação | Memória exibida |
|---|---|
| Tauri — soma dos quatro processos identificados | 176,9 MB |
| Nativa macOS — processo identificado | 73,5 MB |
| Diferença nesta captura | 103,4 MB (aproximadamente 58% menor) |
Observação local fornecida pelo autor; a identificação dos processos foi confirmada por ele.
A comparação usa a soma dos valores exibidos pelo Activity Monitor, não memória física exclusiva. É uma observação pontual: máquina, versão do macOS, commits, modo de build, tamanho da biblioteca e tempo em idle não foram registrados neste case. O endereço localhost indica conteúdo servido localmente na versão Tauri. Os valores não comprovam uma redução geral de memória, consumo de CPU ou tempo de inicialização; uma comparação reproduzível requer condições equivalentes e múltiplas execuções.
Evidências e limites
O case reúne código público, capturas da interface e uma observação local de memória. O foco é documentar o aprendizado em interfaces nativas e o reaproveitamento do núcleo Rust durante o desenvolvimento. Benchmarks comparativos não fazem parte do escopo atual; a captura de memória permanece como registro pontual, sem promessa de desempenho geral.