Letra acompanhando a música, numa janela que fica por cima do que estiver na tela — num desktop onde o gerenciador de janelas é quem decide se isso pode ou não.
Linux primeiro, por um motivo simples: aqui a parte difícil é a janela, não os dados. Descobrir o que está tocando é só ler uma propriedade. Conseguir ficar por cima de uma aplicação em tela cheia é o que realmente decide se a ideia funciona.
O protocolo escolhe o toolkit
No Wayland, um cliente não pode simplesmente escolher onde colocar sua janela ou
mandar ela ficar acima de outra. Isso faz parte do protocolo, e quem toma essa
decisão é o compositor. Para um overlay que precisa continuar visível sobre uma
janela em tela cheia, existe então um caminho específico: wlr-layer-shell, um
protocolo que permite que uma superfície seja tratada como uma camada da tela, em
vez de uma janela comum.
E aí a escolha do toolkit fica bem mais específica: quais toolkits conseguem usar esse protocolo a partir de Rust hoje?
Dois acabaram ficando de fora por motivos que não eram questão de preferência. O
Slint é Rust puro e tem uma API bem agradável, mas usa o winit para desenhar, e
o winit não implementa layer-shell. Existe uma solução de terceiro, mas o
próprio crate diz que ainda não está pronto para produção.
Qt com Kirigami também não encaixou. Não existe uma API Rust oficial para esse
caminho: a opção suportada usa cxx-qt junto com CMake, enquanto a interface é
feita em QML. Isso colocaria uma segunda linguagem e um segundo sistema de build
no projeto.
Decisão
gtk4-rs, com gtk4-layer-shell desde o primeiro commit, em vez de deixar isso
como uma opção para depois. Assim o projeto continua com uma linguagem só, sem
node_modules, e com um binário que fica na casa de poucos megabytes.
Trade-offs
- Aprender GTK4 é um custo real no começo, principalmente nas primeiras semanas.
- A interface é feita em Rust e Pango em vez de CSS, então chegar num acabamento visual bom demora mais.
- Escolher
wlr-layer-shelltambém limita os desktops. O Mutter, usado pelo GNOME, não implementa layer-shell e não pretende implementar. No GNOME, portanto, é preciso pensar em outro caminho. - A libadwaita deixaria a janela de preferências bem mais fácil de fazer, mas o fundo dela entra em conflito com a transparência que o overlay precisa. Por isso ela acaba fazendo sentido em uma janela, mas não na outra.
- Os crates precisam estar alinhados nas versões. Quando há um descasamento, o erro que aparece pode ser um erro de tipo bem confuso em vez de simplesmente dizer que as versões não combinam.