Uma coisa que é bem forte no mundo Linux, é justamente a liberdade dada ao usuário final a como o sistema deve ser. Desde a trocar o Kernel do sistema operacional por algum outro, escolher qual gerenciador de pacotes será utilizado, se o sistema é imutável ou não, com quais aplicações e, o tópico de hoje, a aparência.
Mas nem tudo é um mar de rosas. Por trás dos grandiosos projetos conhecidos no mundo Linux, ainda existem seres humanos, imperfeitos e limitados. Muitos deles dão o melhor de si para trazer soluções em um ecossistema solido e agradável de utilizar. O maior exemplo disso é o projeto GNOME, mais conhecido pelo GNOME Desktop mas também responsável pelo GTK, um kit de ferramentas para criação de interfaces gráficas de usuário, ou GUI, facilitando a criação da mesma para desenvolvedores.
O caso
GTK pode ser modificado com facilidade, utilizando nada mais que CSS para dar a interface uma outra cara, um outro tema. Mas isso também delega ao criador do tema, a responsabilidade de que seu tema funcione como deveria, tendo coesão visual, fácil legibilidade e tudo isso sem deixar de ser funcional. E como desenvolvedor web, eu sei como é fácil quebrar uma customização CSS se um seletor mudar de nome ou uma propriedade mudar seu comportamento. Ou mesmo, se um CSS não foi bem feito e contém bugs visuais ou de usabilidade, deixando a aplicação inutilizável. Eu mesmo já vi isso quando usava temas GTK no inkscape. Alguns desses temas tornava botões ou listas impossível de ser interagidas ou com diversos bugs que atrapalham o trabalho.
Mas até aí tudo bem, certo? É só atualizar o tema para resolver esses bugs ou simplesmente não usar o tema em questão.
Se apenas fosse assim tão simples…
O problema
Muitas distribuições Linux vem com temas aplicados por padrão. Alguns exemplos incluem Ubuntu, Pop!_OS, Zorin OS, Manjaro, Linux Mint e vários outros, independentes ou derivados. Não digo aplicados com o tema padrão GTK, o Adwaita, mas sim temas próprios, fortemente modificados. Modificações essas que alteram o comportamento padrão do GTK, o que por consequência quebra muitas aplicações. Chegou a um ponto que a equipe GNOME teve que pedir formalmente que as distribuições não apliquem temas por padrão, pedido esse que foi solenemente ignorado pelas mesmas.
O motivo
Aplicações criadas com GTK foram testadas com o Adwaita e Adwaita dark, o padrão do GTK, então foi com suas funcionalidades em mente que foram criadas. Os temas não só alteram o visual mas também a forma como as aplicações se comportam, gerando bugs que são reportados para os desenvolvedores das próprias aplicações, que não podem fazer muita coisa a esse respeito por não ser culpa da aplicação mas sim do tema. Agora multiplique isso pela quantidade de usuários que usam um tema quebrado por vir aplicado por padrão no seu sistema. Tudo isso poderia ser evitado, eliminando esses bugs desde o início.
Os desenvolvedores trabalham em suas aplicações, muitas vezes em seu tempo livre, e não podem dizer dezenas ou centenas de vezes que tal bug está sendo causado por um tema. Isso é estressante e desencoraja de ir atrás de bugs reais.
A solução
Para isso, a equipe do GNOME desenvolveu um plugin GTK que permite o uso e configuração complexa de uma GUI que seja uniforme, bonita e funcional. O compromisso seria o encerramento de suporte a temas GTK como conhecidos anteriormente, embora a equipe do GNOME já expressou estar ciente do desejo de manter uma identidade visual, ou branding, de diversas distribuições, então irá permitir a possibilidade de definir cores no libadwaita atravéz de uma API.
A recepção
Aqueles que gostam de customizar o GNOME ou aplicações GTK com temas, não viram a introdução do libadwaita com bons olhos, acreditando que seria uma tentativa de abolir temas por completo, que o projeto não gosta de temas ou até mesmo quer limitar a liberdade do usuário e engessar o GNOME Desktop e GTK. Eu mesmo sou culpado de acreditar nisso e até partilhar da minha opinião a esse respeito aqui no fórum Diolinux Plus.
A realidade não é tão nua e crua dessa forma e os usuários, eu me incluo nesse meio, partiram para um preconceito desnecessário contra a equipe GNOME por algo tão pequeno como temas.
A realidade
A equipe Gnome nunca quis abolir temas ou limitar a liberdade do usuário a respeito de nada. Pelo contrário. GTK e libadwaita continuam sendo customizáveis com CSS, então os customizadores de plantão não teram seus hobbys interrompidos. Esses não são o público alvo do libadwaita, afinal esses já estão cientes, ou pelo menos deveriam estar, de como um tema pode e vai quebrar uma aplicação caso modifique demais como o GTK funcione.
O público alvo do libadwaita é, na verdade, as distribuições que não deram ouvidos ao pedido da equipe em não aplicar temas por padrão em seus sistemas, justamente para os usuários que não estão cientes da parte técnica dos temas e como eles podem quebrar aplicações ou mesmo que existe um tema de terceiros aplicado. Esses, inquestionavelmente, irão reclamar ou passar uma imagem ruim do GNOME, suas aplicações ou aplicações de terceiros que fazem uso do GTK.
E curiosamente, quem mais gostou da introdução do libadwaita, foram justamente esses mesmos desenvolvedores. A adoção do libadwaita pelos mesmos tem sido bem grande. Um exemplo disso é o Bottles, utilitário feito para faciliatar o uso e configuração do Wine para diversas funcionalidades, cujo desenvolvedores já reclamaram sobre distribuições reempacotando o Bottles de forma mal feita ou com problemas de dependências que geram bugs que não existem em sua distribuição oficial pelo Flathub. O Bottles também usa libadwaita por padrão e não vai funcionar com temas GTK em nome da consistência e usabilidade.
A falácia
Alguns podem argumentar que tais problemas apenas existem com GTK, e que isso não acontece com aplicações do projeto KDE ou que usam um framework Qt mais genérico. Mas não é bem assim que a banda toca.
Claro que o projeto KDE não tem um sistema de temas robusto como o de GTK, sendo limitado a estilos de widgets para o QStyles e somente para o QStyles, com o padrão do KDE sendo o Breeze, embora outros existam, como o saudoso Oxygen, MS Windowss 9x, Fusion e até uma implementação do GTK 2. Instalação de novos Widget Styles no KDE não é tão simples como arrastar e soltar como é com o GTK, que usa apenas CSS. Talvez seja até por isso que a engine Kvantum se tornou tão popular, porque se trata apenas de SVGs ou gráficos vetoriais, para criação de temas mais facilitada.
Kvantum é na verdade PIOR!
Já aconteceu várias vezes de, quando eu estava a testar um outro Widget Style, que um deles tenha quebrado por completo, como o que pode acontecer com uma biblioteca que deixa de ser atualizada por muito tempo, ou que torna a usabilidade de aplicações bem difícil ou inutilizável. Há distribuições que instalam pacotes legado junto com o sistema, com o próprio openSUSE, que contém Widget Styles igualmente legado mas que já quebraram há muito tempo, o que torna o sistema operacional completamente inutilizável caso o usuário venha aplicá-lo por curiosidade, a menos que o mesmo saiba como alterá-lo de alguma forma sem usar uma GUI.
Aplicações Qt não são todas iguais
Outro ponto levantado no artigo feito pelo desenvolvedor do Bottles, é que existem várias aplicações Qt que não fazem uso do tema do sistema por padrão. Um exemplo é o OBS Studio, que tem um tema próprio e que, apesar de não ter consistência com o tema do sistema operacional, tem consistência consigo mesmo, sendo perfeitamente utilizável e legível. Mas esse ainda assim permite utilizar o tema do sistema caso queira, embora essa opção venha desativada por padrão. Basta ativá-la para ver que não é a mesma coisa que as aplicações Qt que usam o KDE Frameworks. Então, esse problema de temas existe até mesmo no lado KDE da força, embora não tão visível por ser mais difícil de instalar Widget Styles alternativos, com a opção de troca de esquema de cores sendo mais fácil, disponível desde o início mas igualmente “quebrável” caso o criador de tal esquema de cores não saiba deixar algo legível.
Um compromisso necessário em nome de experiência de usuário
Com tudo isso em mente, é mais compreensível a existência do libadwaita. Não posso dizer que o projeto KDE não tenha algo parecido, já que aplicações Kirigami não fazem uso do Widget Style global mas sim do estilo padrão Kirigami, embora ainda faça uso de esquemas de cores, o que o coloca bem próximo do libadwaita nesse ponto, ainda que não creia que a intenção da criação do Kirigami seja por esse motivo mas sim para a criação de aplicações convergentes.
Para a equipe Gnome, o libadwaita defende a liberdade do usuário de uma forma estranha mas necessária. Ao mesmo tempo que é só um plugin para GTK e não algo imposto, sua adoção rápida mostra a necessidade da mesma. E mesmo com liberdade, não significa caos. Só porque pode, não significa que deve. E quando se trata de computadores e soluções para problemas, não é justo delegar do usuário final, um conhecimento técnico aprofundado sobre como o sistema funciona. E, realmente, muitos nunca terão, e é por isso que esse dilema existe. Sem falar que libadwaita é bonito pacas. xD
Fonte: libadwaita: Fixing Usability Problems on the Linux Desktop | TheEvilSkeleton