Libadwaita pode nunca receber suporte a temas. Veja o motivo

Sim, mas essa evolução é ilógica pelo que ele se propõe a ser, não é necessário ter tanta quebra de API até porque a maioria das quebras são troca de nomes apenas, se pegar um “tema bem feito” vai notar que o que os torna “bem feito” é adicionar várias linhas com diferentes nomes mas com o mesmo valor, isso porque o que mudou foi apenas o nome da propriedade

O Qt podia ser o Iced que seria a mesma coisa, não é o fato do Qt ser um framework é a forma como os dois temas são geridos pelo Qt

Na maioria das plataformas git, o desenvolvedor pode adicionar linhas guias pra limitar como as issues são abertas, e isso significa que o desenvolvedor pode filtrar issues que não batem com uma descrição, por exemplo onde a pessoa não testou com o tema X, ou com o sistema Y, ou o formato Z, o Tomaz por exemplo usa desses filtros nos repositórios dele

Nunca foi muito difícil realizar o bloqueio de temas no GTK, então essa justificativa não parece bater o pessoal dos apps do elementaryOS sempre fizeram isso através do GtkStyleProvider já o visual Index do Libadwaita parece bem mais convidativo, o do Bottles eu não duvido que seja por causa de temas, mas daí atribuir a adoção massiva parece ignorar a principal vantagem do Libadwaita que são os blocos de construção

Novamente, essas aplicações foram feitas e testadas com Adwaita como tema e apenas esse. A parte ilógica é ter que suportar temas mal feitos e não o oposto. Pode querer defender os criadores de temas o tanto que quiser mas o ponto continua sendo temas pré aplicados, como o do Pop!_OS.

Agora por quê eu critico tanto os temas assim? Simplesmente porque as mudanças no GTK não aparecem de repente da noite pro dia. Elas aparecem com muito tempo de antecedência no Git, então é algo que os criadores de temas tem que observar e não criar e abandonar. Mesmo o Ubuntu modificou seu tema para se assemelhar mais ainda com o Adwaita e evitar coisas assim. Aposto que eles seriam os primeiros a adotar a API de esquema de cores do libadwaita, enquanto o Fedora não precisa porque já modificam o Gnome o mínimo possível.

“Geridos pelo Qt”, parece que você ainda não entendeu como o Qt por si só não gerencia temas (nem transparência, o que depende de outro plugin). Só aparenta ser por causa da forma como essas aplicações são chamadas coloquialmente. Diferente do GTK, que força um stylesheet global, Qt não faz isso e só aparenta ser o caso por causa do uso popular do QStyles. Diversas aplicações Qt que não fazem uso disso e ainda não entendeu? Essa conversa está ficando chata…

Isso assumindo que quem abre as issues vão saber que estão com um tema pré aplicado ou que o problema está sendo causado por um tema. Ou você não leu justamente isso sobre suporte no artigo do mantenedor do Bottles? Até mesmo com sugestões de recusar dar suporte a menos que a aplicação esteja usando Adwaita e não outro tema, isso fica chato. Tente praticar ser o advogado do diabo uma vez. Inverta seu pensamento e tente entender o motivo da equipe do Gnome pedir formalmente que as distros não embarquem com temas pré aplicados. Houve até uma carta aberta de vários devs pedindo com gentileza para pararem de botar temas em seus apps. Eu recomendo dar uma lida aí. E por favor, eu espero que sua conclusão não seja de que estão todos errados. Devs são gente também e merecem estar com a família e amigos no tempo que estão, no lugar, filtrando issues que são causadas por temas e ainda desacelerando o processo de desenvolvimento e manutenção. Existem problemas legítimos nesse meio e imagina a frustração ter que examinar milhares linhas de código, recompilar e ver que o problema não acontece nos seus testes mas naquela máquina em específico acontece. Depois de eliminar as outras variáveis, o que sobrou sendo temas. Esse pedido foi feito com um motivo.

Eu não ignorei as vantagens. Eu apenas evitei fugir do tema, algo que você não se importou muito, que é justamente o motivo do libadwaita nunca receber suporte a stylesheets customizados. Eu sei bem que o libadwaita facilita muito a criação de uma GUI, afinal estava logo no artigo do criador do Bottles.

Sobre bloquear temas no GTK, isso foi falado sobre na carta aberta:

image

“A nível de plataforma, acreditamos que GTK deveria parar de forçar uma única stylesheet em todos os apps por padrão. No lugar dos apps terem de forçar um stylesheet já no código, eles deveriam usar a stylesheet da plataforma a menos que escolham fazer uso de alguma outra coisa. Nós sabemos que isso é algo complicado, mas esperar que todo app irá funcionar com qualquer stylesheet é um padrão ruim”

Aqui mostra a situação com temas e como criar uma GUI com o tema padrão em mente e vê-la quebrar com temas é especialmente frustrante. Um exemplo disso é o modo Dark da MIUI, interface customizada dos celulares da Xiaomi e subsidiárias. Há um tempo atrás, esse modo dark apenas invertia as cores de certos elementos nos aplicativos, o que incluia fotos subidas pelos usuários, então não era limitado a interface do app.

Até hoje isso acontece, como é o caso do Twitter, mas outros apps foram forçados a implementar código para remediar isso. No caso da MIUI não é tão ruim assim fazer porque é extremamente popular mas o ponto é que não deveria ser necessário. Mas até aí tudo bem. O problema só se agrava quando vimos para o mundo Linux, onde stylesheets customizadas existem aos montes e seria complexidade desnecessária, ter de adotar tudo isso. Tente se colocar na pele desses devs. Recusar suporte é ruim para o feedback. Mudar a licensa para proibir customização não é amigável para a filosofia do software livre. E ter de suportar temas não oficiais é frustrante. Ao invéz de buscar um culpado ou dizer que poderia ser resolvido se o GTK parasse de mudar o nome ou propósito de seletores, entender os dois lados vai ser saudável para você e os que estão ao seu redor e ajudar a formar uma opinião justa. Belê? :+1: (Poxa, eu uso KDE Plasma, não Gnome. LOL)

Agora bora por favor encerrar essa conversa por aqui porque está ficando chato.

1 curtida