Libadwaita pode nunca receber suporte a temas. Veja o motivo

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

20 curtidas

Disse tudo. Eu uso um tema que emula o MacOs apesar de gostar muito de um GNOME puro simplesmente por questão de gosto, mas tenho plena noção de onde esse tema funciona e onde não funciona, a loja do Pop, algumas aplicações ficam com letras com a mesma cor do fundo e etc, porém é um contra que eu aceito para me manter usando os temas que eu gosto.

No fim das contas, eu acho que o maior problema desse debate seja justamente das distros que modificam o GNOME ao ponto de quebrar o GTK em algumas aplicações, não vejo isso como uma forma de impedir a utilização de temas, até porquê, se o GNOME fala “Cara, não modifica o tema, pode quebrar e eu não tenho responsabilidade sobre isso” e a distro vai e modifica, assume o risco de problemas.

Eu vejo esse mesmo problema quando as aplicações são empacotadas em um formato que não é suportado ou apoiado pelo dev original da aplicação, acontece algum bug que vem do empacotamento e não do dev, o usuário reclama com o dev e não com o mantenedor do pacote, isso cria um ciclo de estresse bem chato pra qualquer pessoa, imagina alguém falar que a sua aplicação tá bugada mas a culpa nem sua é, porém termina caindo em ti por ser o desenvolvedor dela.

Esse e outros são mais um dos “calcanhares de aquiles” do Linux.

10 curtidas

Sim! O gnome não está com uma posição contra temas em geral mas apenas pensando na questão de suporte ao usuário. Muitos daqueles support tickets podem muito bem serem causados por temas, o que é chato para os mantenedores. Quem aplica tema manualmente, eventualmente vai descobrir isso sobre temas quebrarem. Mas quem tem um sistema com um tema pré aplicado vão saber disso? Duvido que saibam que tem um tema pré aplicado ou que dá para aplicar temas! Por isso que o libadwaita existe.

Agora sobre empacotamento mal feito, esse é mais um dos motivos de eu não gostar de usar o Archlinux mais ou derivados como o Manjaro. Eu esbarrei em um monte de pkgbuilds que simplesmente não funcionam, que dão erro de compilação ou no geral são muito mal feitos, muitos deles desenpacotando .deb ou .rpm sem se importar com as versões de dependências que esses pacotes precisam, algo crucial para o Archlinux justamente por ser Bleeding Edge. Eu não consigo acreditar como é que tem tanta gente com tempo de sobra para gerenciar uma instalação do Archlinux. Como dizia um meme, é falta de namorada!

Por isso que eu não uso mais o Archlinux ou derivados. E teve uma galera tentando me convencer a migrar do openSUSE. Se for para desenpacotar um .rpm ou compilar, pelo menos eu já uso um sistema que usa .rpm que já é feito para ele. E raramente preciso compilar alguma coisa porque tem no Flathub ou no Build Service. Essa instalação minha tem mais de ano de idade, enquanto Manjaro quebrava com poucos meses de idade comigo.

7 curtidas

Exato, claro que as distros podem e devem por algo que as diferencie das outras, quando pensamos em marketing, até porquê o usuário final vai ter a experiência da DE da distro, então se 5 distros usam o GNOME o workflow das 5 será igual. Agora, quando elas personalizam para criar uma identidade própria, temos algumas que fazem um trabalho bem feito como o Zorin que usa o GNOME por padrão mas consegue emular diferentes DE, já tem outras que modificam tanto que vez ou outra você esbarra com bugs (Pop! estou falando de você)

O ideal, é realmente a introdução do libadwaita permitindo que as distros façam algumas customizações para criarem sua própria identidade como é o proposto, até nesse artigo que você mandou. Quem quiser fazer algo muito fora da curva, que faça bem feito.

pain, just pain.

1 curtida

O mundo dos desenvolvedores para Linux está se ajustando a essa questão do Libwdwaita e outas relacionadas ao GTK. Quem prioriza uma alta liberdade de inventar temas e de “montar” o visual e a interface de sua distro decidiu providenciar ambiente gráfico sobre novas bases. Nos próximos anos teremos o Budgie sobre a biblioteca EFL (a mesma do Enlightenment) e o Cosmic do Pop!_OS em RUST.

3 curtidas

Isso ocorria com pacote dos repositórios oficiais?

Sim. Coisas pequenas mas ainda sim. Uma das que eu vi foi a falta de declaração do StartupWMClass que fazia os ícones aparecerem duplicados na barra de tarefas. Eu tinha falado em outro tópico que isso não é problema de DE mas sim do empacotamento, que não atualiza as .desktop que conectam uma janela a seu ícone.

Mas isso era de menos. O problema real estava no AUR. Tem um monte de “pacotes” no AUR que estavam quebrados em algum lugar, dando bugs ou simplesmente dando falha de compilação, não instalando por motivo algum. E isso é especialmente irritante quando se algo não está nos repositórios oficiais, tem que torcer estar no AUR e funcionando bem. Isso e se tiver em flatpak mas aí qualquer distro serve

1 curtida

Assim, eu realmente entendo a motivação do GNOME mas parte disso é culpa deles mesmo, essas incompatibilidades de temas surge de instabilidade do próprio GTK, experimenta aplicar o tema GTK do Lubuntu 16.04 no 18.04 no mesmo app, na mesma versão do app só compilado com uma versão mais recente do GTK… quebra tudo que antes não quebrava, piora no 20.04 alguns apps nem abrem


Fora isso 2 pontos:

A adoção do Adwaita penso eu, se dá por ele ser uma galeria de widgets comuns mas ignorados pelo GTK, travar temas sempre foi relativamente simples

Já nessa eu concordei com o titulo mas descordei do desenvolvimento, o Qt funciona no modelo tudo ou nada, então Widget escuro, mais tema de ícones brancos quebra mesmo e com o libadwaitta pelo menos onde eu pude testar o problema foi importado pro GTK

1 curtida

O Joshua é mais que “anti libadwaita” ele é anti GNOME no geral…embora use software do GNOME para desenvolver a sua DE…

2 curtidas

O que importa é o conteúdo das críticas ao GNOME e à postura de seus desenvolvedores. Há muitos pontos bons nas críticas. Ademais, no momento em que as diferenças ficam inconciliáveis, o razoável a quem pode é abrir seus próprios caminhos alternativos, e isso o pessoal do Budgie e do Pop!_OS teve a coragem de fazer.

2 curtidas

Mas a responsabilidade de manter o temas compatível com as mudanças e atualizações do GTK é de quem fez o tema e não da Distro ou da Equipe do Gnome/GTK;

Eu entendo o ponto da comunidade e ponto dos desenvolvedores do Gnome mas convenhamos, com tantas distros, temas e customizações de temas onde além dos desenvolvedores tem o usuário querendo mexer em trocentas coisas para deixar ao seu gosto ( não tem problemas em fazer isso) o resultado final disso é um mini caos. A anos se falam em padronização mais nunca vamos chegar a lugar algum.

2 curtidas

Exatamente! Colocar a culpa no gnome não faz sentido algum. Eu desafio a qualquer um modificar o CSS de um site, travar esse CSS e ver se ele não vai quebrar esse site quando ele atualizar. A mesma coisa acontece com GTK, que também usa CSS para temas. Não é culpa do GTK ou do GNOME coisa alguma mas sim de quem modificou o CSS mas não atualizou. Seria a mesma coisa de dizer que a culpa de um driver não funcionar é da Microsoft e não de quem fez o driver. Mas quem usa Windows vai saber o que diabos é um driver? Quem tem conhecimento mais avançado em computador vai, mas o usuário comum vai achar que o computador não presta.

4 curtidas

Na minha opinião dois erros bem grandes, mas eu não sou o responsável por manter as distros.

Mas perder o suporte a acessibilidade e tradução pra tudo quanto é língua fantásticos que o GNOME tem pra correr atrás de ter que fazer tudo isso por conta própria do zero (quando o Pop não consegue nem sequer traduzir direito as extensões do GNOME que eles fizeram pra criar o workflow deles) é pedir pra ter uma situação Unity de novo. O pessoal do Budgie pelo menos parece ser bem responsável nesse aspecto, mas pelo que eu vi tem pouquíssima staff dedicada ao projeto hoje em dia, vai ser uma tarefa desnecessariamente grande pra esses caras.

4 curtidas

Perdão meu amigo mas você não entendeu a explicação. Creio que você leu os termos mas como não entendeu, ignorou e fez a explicação não fazer sentido. Os temas GTK não são nada muito diferentes de um estilo CSS usado em páginas da internet, que possuem seletores e propriedades, então são os temas GTK que definem o comportamento do mesmo, não o GTK em si. Quer ver como ele deveria funcionar? Veja o tema Adwaita.

Novamente, você não entendeu como temas GTK funcionam. A galeria de widgets vem sempre melhorando, o motivo de existir versionamento do GTK. Mas novamente, depende do tema Adwaita padrão para que funcione como deveria. Temas alternativos modificam esse comportamento e vão SIM quebrar os widgets se até um z-index for dado ou até mesmo, omitido. libadwaita padroniza isso tudo de uma forma que os widgets funcionem e dá mais opções e propriedades que seriam consideradas complexas para o GTK só com Adwaita padrão. Não confunda o Adwaita com libadwaita.

Novamente um equivoco. Qt é muito maior do que vemos no mundo Linux e no projeto KDE. O KDE não usa nem metade do que o Qt permite. Não é uma alternativa a apenas o GTK mas a um monte de coisa. Você tem o QStyles para receber temas mas ainda tem o QML como linguagem de notação de hipertexto, parecido com o HTML e XML, mas aí como ele é usado se QML não é em C++ como o resto de Qt? Isso só para nomear alguns. Quando eu disse que aplicação Qt não é tudo igual, você acha que todos usam os frameworks do KDE como o kxmlui? Ou o Kirigami? Esses são galerias de widgets também, o Kirigami até com um visualizador para Android e outro para Linux Desktop. Compare isso com as aplicações Qt que usam outro framework. Quer adicionar transparência a uma aplicação Qt? Com apenas Qt é impossível mas com um framework Qt como o do KDE mas a galeria de widgets Lightly, é possível. Se o Qt dá a ilusão de ser tudo ou nada, talvez seja porque sua solução Qt seja compatível com o QStyles. Mas existem aplicações que não usam o QStyles, como meu exemplo do Kirigami

Concordo com suas ponderações. É deixar para trás a mais sólida das bases entre os ambientes gráficos. Mas aplaudo a coragem, a ousadia. Aliás, eu gostaria muito de ver um ambiente gráfico tão elegante quanto leve, além dos pouco comentados Moksha e Enlightenment, e o novo Budgie tem tudo para ser assim.

Essas aberturas de “novos caminhos” me lembram os surgimentos do MATE e do meu ambiente gráfico preferido, que é o Cinnamon. Mas estes ainda têm vínculos com a base GNOME, embora cada vez mais distantes.

2 curtidas

É isso, eu torço muito para que dê certo e que os resultado sejam maravilhosos (até porque como fanboy de Rust seria um use-case bem inovador pra linguagem, no caso do Pop), mas dificilmente consigo enxergar isso dando muito certo no longo prazo.

2 curtidas

Assim, eu não creio que seja um erro pela parte da equipe do Budgie de adotar o EFL. Até o momento, o Budgie Desktop era um fork do GNOME 3, até necessitando o Gnome shell instalado para várias das dependências alinharem. Conforme o Gnome vai evoluindo e modificando como o mesmo funciona, o Budgie tem que acompanhar essas mudanças ou vai quebrar. Mas e se houver uma mudança drástica como com o Gnome 40 e GTK 4? Sim, esses parecem não mudar muito na superfície mas pode ser uma dor de cabeça para quem mantém uma modificação do GNOME 3 e quer mantê-la assim. O licenciamento do Qt também parece nebuloso e o futuro com o Qt 6 é bem confuso a esse respeito. Então o que sobra? GTK evolue tanto que criar um fork vai criar aplicações que não terão compatibilidade entre o Gnome e o Budgie ao longo prazo, então uma escolha é romper compatibilidade por completo e não ter que lidar com isso. Mas é claro, é apenas uma hipótese minha. Não tome por garantido. A equipe do Budgie pode ter melhores motivos para não adotar nem GTK nem Qt mais. E o Pop OS criando um desktop em Rust parece criar um toolkit novo porque Rust é só uma linguagem de programação compilada, não um toolkit como GTK ou Qt

6 curtidas

@tiagoquintino @ryu_ketsueki

Imagino que não entenderam meu ponto, GTK e Qt usam o mesmo mecanismo pra tema, a diferença é que o Qt também suporte Engines estilo GTK, a principal diferença está na estabilidade de API do CSS, enquanto o exato mesmo estilo feito pra estilizar um componente feito pro 4 funciona sem qualquer quebra no Qt 6, o máximo que acontece é você não ter alguma propriedade opcional

Mas meu ponto não é esse, eu sei que o CSS do GTK é o mesmo que o da internet, essas quebras entre versões ocorrem por depreciação, remoção e alterações de propriedades, por exemplo, se o “tema” é escuro, e a propriedade que define a cor dos textos é a text-color mas numa próxima release do GTK mudam pra color (não sei se foi assim que aconteceu ou foi o oposto, mas o efeito é o mesmo) o texto vai ficar invisível ou pelo menos com uma cor próxima a do fundo, a esmagadora maioria das issues de “temas” GTK são devido a isso

Mas eu não estava falando de temas, eu só acho improvável que a adoção massiva do Adwaita se deve a implementação facilitada de componentes comuns na maioria dos apps, querendo ou não com Libadwaita você consegue criar widgets, veja esse por exemplo, é um inferno fazer em GTK puro com Libadwaita vc tem apenas um único contructor que já monta o container, os componentes e o ícone e os signals de uma vez só, é muito mais prático

Sim eu sei mas de novo não passou perto do que eu quis dizer, o Qt funciona em um modelo híbrido nesse ponto:

  • App inicia
  • Carrega o QPlatformPlugin
  • Carrega o QStyle associado

Então faz as overrides:

  • Carrega o QSS (a variante CSS do Qt)
  • Carrega o tema de ícones do sistema (se não houver um override)
  • Exibe o app

Aí que mora o problema de interpretação do autor: se o QStyle e o QSS forem um “tema” escuro" mas o tema de ícones for para interfaces “Light” acontece aquele problema, ou seja independente de ser QML ou QWidget o Qt espera por padrão que o QStyle e o QSS estejam em harmonia, ou você tem tudo ou você acaba não tendo nada, devo ter um ou outro exemplos no meu GitHub demonstrando isso

Acaba que você provou o ponto da existência do libadwaita e do motivo do Gnome pedir para as distros não pré aplicarem temas em seus sistemas, justamente por causa de como o GTK evolue e temas não evoluem com eles. Esse é o ponto da existência do libadwaita. Não é culpa do Gnome mas sim das distros que colocam temas mal feitos. Veja o tema GTK do Pop!_OS. Texto escuro em tema dark? Ou mesmo usar tema GTK no Inkscape. Eu tive que remover os temas de terceiros e voltar para Adwaita para ter o Inkscape funcionando normalmente e você vem me dizer que isso é culpa do GNOME e não da galera que não fez um tema direito? Atualização do GTK pode influenciar isso mas é dever de quem criou os temas de acompanhar os patch notes do GTK a cada atualização. Ou você vai me dizer que agora é culpa dos navegadores de internet se um site quebra ao invéz dos mantenedores do dito site se seu CSS faz uso do Masonry quando ainda não é suportado? Agora entende o motivo do seu raciocínio estar equivocado? Não quero ficar me repetindo quando o ponto já foi explicado no artigo. Mas pela última vez, se resume a suporte. Se a aplicação foi CRIADA e TESTADA usando Adwaita e os temas quebram com temas alternativos, é culpa do GNOME? Ah, meu amigo. Eu discordo completamente contigo.

Então você também não leu o artigo que o criador do Bottles fez sobre o assunto. Ele mesmo expressou o desencorajamento de criar uma GUI no geral por causa da situação que o GTK está por causa de temas e como existem tantos tickets de bugs que são causados por temas. Ele só foi tomar iniciativa quando viu a forma que o libadwaita funciona, que pode ser resumido a uma palavra. Uniforme. Não ter de se preocupar se a aplicação vai funcionar nos temas mais populares mas sim apenas com um só, o libadwaita. Se fosse por causa de widgets complexos, programas simples como um gravador de tela ou de voz não precisariam usar o libadwaita. Mas usam porque é uniforme. Eu mesmo uso o Emulsion, que apenas guarda as paletas de cores que eu uso, algo que, pessoalmente, eu poderia fazer em pouco tempo usando apenas HTML e CSS, então não se trata de “widgets impossíveis com GTK padrão mas possíveis com libadwaita”. Se trata de uniformidade, algo que o libadwaita traz.

O que você citou são alguns plugins do Qt. As aplicações podem escolher utilizá-las ou não, da mesma forma como aplicações GTK podem escolher usar libadwaita ou não. Da mesma forma, Aplicações Qt podem usar QtWidgets, QML ou QSS ou algum outro, podem suportar ou não QStyles, como eu mostrei Kirigami não usando, junto da suite de aplicações Maui. Eu mesmo já brinquei com QML e modifiquei widgets do KDE Plasma e vi como a linguagem é completamente diferente do CSS. Não saberia dizer em relação ao QSS

Quer conhecer aplicações Qt que não usa nenhum desses plugins aí, não parecem em nada com as aplicações Qt que você conhece mas ainda usam Qt? Toda a suíte de aplicações do Deepin. Parece GTK mas vá mudar o tema GTK no deepin para ver o que acontece. As aplicações do Deepin permanecem exatamente as mesmas. Se são afetadas por um toggle de tema dark ou não, talvez seja porque use portals ou algum padrão Free Desktop a esse respeito mas não deixa de ser um Qt extremamente diferente do KDE Frameworks, por exemplo. Unity 8 também usando Qt no shell (e acho que o UKUI também usa Qt, embora não seja afetado por QStyles ou nada). Alguns programas da Adobe também usam Qt, como o Photoshop Album e Photoshop Elements. Recebem temas do QStyles? Não testei para ver se dá. Tá aí algo que vale a pena testar. E a lista só cresce se for ver a página do Wikipedia a esse respeito:

Spectacle_20220803_105753

Mas o ponto continua o mesmo. A culpa não é da Qt Foundation se o seu tema não foi feito direito, e esse é o ponto que você não entendeu. Esse seu “tudo ou nada” esqueceu da complexidade e plugins necessários para uma aplicação Qt funcionar, dentre tantos que podem fazer a mesma coisa. E de quem é a culpa se algo quebrar por causa de temas? Não é de quem fez a aplicação Qt. Ou você está ensinuando que dev tem que ficar feito barata tonta e suportar tudo quanto é tema que aparece nos support tickets, mesmo que sejam incompatíveis um com o outro, criando complexidade desnecessária? Não é culpa da Qt Foundation nem de quem fez sua aplicação em Qt então só sobra dos temas. O escopo de uso do Qt é muito maior do que o de GTK, por isso essa comparação não funciona. Ponto final.

4 curtidas

Olhando para o lado do desenvolvedores é totalmente plausível ter esses motivos.

2 curtidas