Antes de começar, vamos resolver isso, porque o delírio de uma semana nas redes sociais já se arrastou o suficiente.
Sim, o libadwaita vair “hardcodes” Adwaita. Sim, os aplicativos, como estão, não seguirão um tema de sistema personalizado. Sim, isso melhora o comportamento padrão do aplicativo para GNOME quando executado em outras plataformas como o Elementary OS. No entanto, isso é o resultado de uma limitação técnica, e não de uma conspiração maligna como o Twitter continuará dizendo a você …
A razão é que para que o High Contrast (e o próximo Dark Style) funcione, a libadwaita precisa sobrescrever a propriedade do nome do tema para que não volte ao estilo “Default” High Contrast do GTK. O estilo “Padrão” é uma versão mais antiga do Adwaita, não o estilo do seu sistema.
Comparado ao GTK 3, não há uma nova maneira de aplicar o estilo “codificado”. A variável GTK_THEME ainda funciona, assim como gtk.css e provavelmente 3 outras maneiras de fazer isso. O processo de criar um tema para seu sistema pode ser um pouco diferente em comparação ao GTK 3, mas ainda funcionará. Da mesma forma, se você estiver desenvolvendo uma distribuição, terá controle do produto final e poderá fazer o que quiser com o código. Existe uma infinidade de opções disponíveis. Aparentemente, reclamar nas redes sociais e intimidar os voluntários até a apresentação era uma dessas opções…
E eu acho que isso também precisa ser declarado: essa mudança afeta apenas os aplicativos que optam por usar libadwaita e adotam as Diretrizes de Design do GNOME, não “todos” os aplicativos GTK 4.
Como de costume, o fato de os temas continuarem funcionando, não significa que sejam compatíveis. Os mesmos problemas continuam sobre o restyling de aplicativos quando eles não esperam que se apliquem e o GNOME não pode dar suporte de forma realista a folhas de estilo arbitrárias que nenhum dos contribuidores desenvolveu e testou.
Agora a postagem real do blog
Parece haver alguma confusão quando se trata da folha de estilo e APIs de coloração da libadwaita. É fácil misturá-los quando você nunca ouviu falar de libadwaita antes, então aqui está uma breve introdução sobre o que são e como diferem.
Lembre-se de que os recursos discutidos abaixo não têm garantia de lançamento. Após a libadwaita 1.0, a folha de estilo será congelada e tratada como uma API. Isso significa que se um recurso não chegar à 1.0, será uma alteração importante e terá que esperar pela libadwaita 2.0.
Um aplicativo para colorir API / cores de destaque
A ideia aqui é que você pode definir cores de “destaque” a serem aplicadas em várias partes dos widgets. Você também pode recolorir qualquer parte de um widget como quiser. Dê uma olhada na barra de cabeçalho do modo privado da Epiphany para um exemplo. Para que isso fosse possível, toda a folha de estilo teve que ser retrabalhada. Cuidado extra foi necessário para garantir que a funcionalidade não entrasse em conflito com a preferência de alto contraste e não precisasse de tratamento especial. Espero que Alexander faça um blog sobre esse trabalho com mais detalhes, pois foi realmente fascinante. Estou muito animado para ver o que os desenvolvedores fazem com a API de coloração.
Por enquanto, as cores podem ser controladas com @ define-color específico do GTK , semelhante às variáveis CSS. A API programática será adicionada mais tarde, conforme a poeira assente. A API será baseada no AdwStyleManager que está sendo introduzido pela preferência de estilo Dark MR e ainda não foi implementada.
Aqui está um exemplo rápido:
Aplicativo GNOME Patterns mostrando os recursos dos estilos CSS.
Para um exemplo mais detalhado do que você pode fazer, verifiquem a postagem recente do blog de Federico .
Destaques do sistema
Isso é fortemente inspirado nas configurações de destaque do ElementaryOS e é semelhante em função. Pense nisso como uma maneira de definir a cor de destaque em todo o sistema, então os aplicativos podem lê-la e decidir segui-la ou substituí-la. Um caso em que você deseja substituir seria se seu aplicativo tivesse um modo Sépia, por exemplo.
A API de coloração mencionada acima é projetada de uma maneira que torna esse recurso fácil de implementar. A interface e a IU para isso ainda não estão completamente definidas e é discutível se será implementado / mesclado. Existem algumas questões e preocupações de design que precisam de mais pesquisas. É uma possibilidade, mas não aposte nisso.
Imagem do painel de configurações de aparência do Elementary OS 6.
Estilo do vendedor
A história por trás dessa ideia é extensa e é melhor deixar para outro post, então aqui está o status atual sobre esse assunto infame.
Houve grandes realizações para reduzir a possível queda de aplicações de restyling com cores de marca. Hoje em dia, os fornecedores reconhecem que o restyling arbitrário pode ser prejudicial para os desenvolvedores de aplicativos e tomaram alguns cuidados.
O Yaru reformulou seu estilo e o reformulou com base no Adwaita, o que ajudou a reduzir as alterações, principalmente na paleta de cores e pequenos ajustes estilísticos. Isso eliminou muitos bugs que apareciam nos aplicativos, já que o Yaru agora tem pelo menos o mesmo espaçamento, margens e preenchimento que o Adwaita. Pop! _OS seguiu o exemplo logo depois, acredito que agora é baseado em Yaru.
No entanto, tanto o Ubuntu quanto o Pop também introduziram os “modos escuros”, o Pop tornando-o o padrão, o que quebrou as expectativas dos aplicativos. Eles fizeram isso apesar de serem avisados sobre isso. Como resultado, isso acabou aumentando os problemas com os temas em cerca de uma ordem de magnitude, pois agora você frequentemente acabaria com preto sobre preto, cinza com cinza e outros bugs divertidos de colorir. Também deve ser notado que nem o Ubuntu nem o System 76 abordaram qualquer contribuidor que eu conheço, sobre a implementação adequada de uma preferência de estilo Dark upstream, mesmo que contribuidores do GNOME e do Elementary tenham colaborado abertamente nos últimos 3 anos.
Captura de tela do gedit com a folha de estilo Yaru Dark, onde o texto selecionado fica invisível.
Os desenvolvedores do Yaru fizeram algumas pesquisas sobre o assunto e houve uma chamada para o envolvimento do GNOME, mas, infelizmente, desde o último tema do BoF em 2019, a conversa parou. As partes interessadas não forneceram nenhum detalhe sobre qual deveria ser o escopo da API, como seria a aparência ou os requisitos detalhados. Ninguém se apresentou para ajudar com as mudanças do Adwaita que eram necessárias, ou com o modo escuro, ou para trabalhar nas ferramentas de controle de qualidade, ou para descobrir os detalhes de implementação. Agora, infelizmente, não temos mais tempo para a libadwaita 1.0 e não há muita esperança de que algo tão complexo esteja pronto nos próximos 4 meses.
Conclusão
Para libadwaita 1.0 e GNOME 42, o trabalho de recolorir widgets provavelmente será concluído. Uma configuração adequada de estilo escuro provavelmente também será implementada até então. As cores de destaque de todo o sistema estão sendo discutidas e analisadas, mas há preocupações relacionadas ao design sobre elas, então é possível que nunca caiam. E não haverá nenhuma “API de Temas” para libadawaita 1.0. Talvez haja um interesse renovado dos fornecedores que querem isso no futuro, mas, dada a história até agora, não vou prender a respiração. Espero ser provado que estou errado.
https://blogs.gnome.org/alatiera/2021/09/18/the-truth-they-are-not-telling-you-about-themes/
Bônus:
A história curta é que GTK3 nunca teve temas, apenas frameworks CSS que algumas distros e usuários têm tratado como temas. E, claro, se você trocar o Bootstrap pelo Tailwind, seu site vai quebrar. Isso geralmente deixa muitas pessoas loucas.
Sim, o libadwaita vair “hardcodes” Adwaita. Sim, os aplicativos, como estão, não seguirão um tema de sistema personalizado. Sim, isso melhora o comportamento padrão do aplicativo para GNOME quando executado em outras plataformas como o Elementary OS. No entanto, isso é o resultado de uma limitação técnica, e não de uma conspiração maligna como o Twitter continuará dizendo a você …
A razão é que para que o High Contrast (e o próximo Dark Style) funcione, a libadwaita precisa sobrescrever a propriedade do nome do tema para que não volte ao estilo “Default” High Contrast do GTK. O estilo “Padrão” é uma versão mais antiga do Adwaita, não o estilo do seu sistema.
Comparado ao GTK 3, não há uma nova maneira de aplicar o estilo “codificado”. A variável GTK_THEME ainda funciona, assim como gtk.css e provavelmente 3 outras maneiras de fazer isso. O processo de criar um tema para seu sistema pode ser um pouco diferente em comparação ao GTK 3, mas ainda funcionará. Da mesma forma, se você estiver desenvolvendo uma distribuição, terá controle do produto final e poderá fazer o que quiser com o código. Existe uma infinidade de opções disponíveis. Aparentemente, reclamar nas redes sociais e intimidar os voluntários até a apresentação era uma dessas opções…
E eu acho que isso também precisa ser declarado: essa mudança afeta apenas os aplicativos que optam por usar libadwaita e adotam as Diretrizes de Design do GNOME, não “todos” os aplicativos GTK 4.
Como de costume, o fato de os temas continuarem funcionando, não significa que sejam compatíveis. Os mesmos problemas continuam sobre o restyling de aplicativos quando eles não esperam que se apliquem e o GNOME não pode dar suporte de forma realista a folhas de estilo arbitrárias que nenhum dos contribuidores desenvolveu e testou.
Agora a postagem real do blog
Parece haver alguma confusão quando se trata da folha de estilo e APIs de coloração da libadwaita. É fácil misturá-los quando você nunca ouviu falar de libadwaita antes, então aqui está uma breve introdução sobre o que são e como diferem.
Lembre-se de que os recursos discutidos abaixo não têm garantia de lançamento. Após a libadwaita 1.0, a folha de estilo será congelada e tratada como uma API. Isso significa que se um recurso não chegar à 1.0, será uma alteração importante e terá que esperar pela libadwaita 2.0.
Um aplicativo para colorir API / cores de destaque
A ideia aqui é que você pode definir cores de “destaque” a serem aplicadas em várias partes dos widgets. Você também pode recolorir qualquer parte de um widget como quiser. Dê uma olhada na barra de cabeçalho do modo privado da Epiphany para um exemplo. Para que isso fosse possível, toda a folha de estilo teve que ser retrabalhada. Cuidado extra foi necessário para garantir que a funcionalidade não entrasse em conflito com a preferência de alto contraste e não precisasse de tratamento especial. Espero que Alexander faça um blog sobre esse trabalho com mais detalhes, pois foi realmente fascinante. Estou muito animado para ver o que os desenvolvedores fazem com a API de coloração.
Por enquanto, as cores podem ser controladas com @ define-color específico do GTK , semelhante às variáveis CSS. A API programática será adicionada mais tarde, conforme a poeira assente. A API será baseada no AdwStyleManager que está sendo introduzido pela preferência de estilo Dark MR e ainda não foi implementada.
Aqui está um exemplo rápido:
CSS:
@define-color accent_color @yellow_5;
@define-color accent_bg_color @yellow_2;
@define-color accent_fg_color black;
.controls {
color: white;
background: linear-gradient(to right, shade(@blue_3, .8), @purple_2);
}
.slider > trough > highlight {
background: linear-gradient(to left, shade(@red_1, .8), @yellow_4);
}
.controls textview text {
background: none;
}
.controls entry,
.controls spinbutton,
.controls textview {
background-color: alpha(black, .15);
color: white;
}
.navigation-sidebar,
headerbar {
background: alpha(white, .1);
color: white;
}Aplicativo GNOME Patterns mostrando os recursos dos estilos CSS.
Para um exemplo mais detalhado do que você pode fazer, verifiquem a postagem recente do blog de Federico .
Destaques do sistema
Isso é fortemente inspirado nas configurações de destaque do ElementaryOS e é semelhante em função. Pense nisso como uma maneira de definir a cor de destaque em todo o sistema, então os aplicativos podem lê-la e decidir segui-la ou substituí-la. Um caso em que você deseja substituir seria se seu aplicativo tivesse um modo Sépia, por exemplo.
A API de coloração mencionada acima é projetada de uma maneira que torna esse recurso fácil de implementar. A interface e a IU para isso ainda não estão completamente definidas e é discutível se será implementado / mesclado. Existem algumas questões e preocupações de design que precisam de mais pesquisas. É uma possibilidade, mas não aposte nisso.
Imagem do painel de configurações de aparência do Elementary OS 6.
Estilo do vendedor
A história por trás dessa ideia é extensa e é melhor deixar para outro post, então aqui está o status atual sobre esse assunto infame.
Houve grandes realizações para reduzir a possível queda de aplicações de restyling com cores de marca. Hoje em dia, os fornecedores reconhecem que o restyling arbitrário pode ser prejudicial para os desenvolvedores de aplicativos e tomaram alguns cuidados.
O Yaru reformulou seu estilo e o reformulou com base no Adwaita, o que ajudou a reduzir as alterações, principalmente na paleta de cores e pequenos ajustes estilísticos. Isso eliminou muitos bugs que apareciam nos aplicativos, já que o Yaru agora tem pelo menos o mesmo espaçamento, margens e preenchimento que o Adwaita. Pop! _OS seguiu o exemplo logo depois, acredito que agora é baseado em Yaru.
No entanto, tanto o Ubuntu quanto o Pop também introduziram os “modos escuros”, o Pop tornando-o o padrão, o que quebrou as expectativas dos aplicativos. Eles fizeram isso apesar de serem avisados sobre isso. Como resultado, isso acabou aumentando os problemas com os temas em cerca de uma ordem de magnitude, pois agora você frequentemente acabaria com preto sobre preto, cinza com cinza e outros bugs divertidos de colorir. Também deve ser notado que nem o Ubuntu nem o System 76 abordaram qualquer contribuidor que eu conheço, sobre a implementação adequada de uma preferência de estilo Dark upstream, mesmo que contribuidores do GNOME e do Elementary tenham colaborado abertamente nos últimos 3 anos.
Captura de tela do gedit com a folha de estilo Yaru Dark, onde o texto selecionado fica invisível.
Os desenvolvedores do Yaru fizeram algumas pesquisas sobre o assunto e houve uma chamada para o envolvimento do GNOME, mas, infelizmente, desde o último tema do BoF em 2019, a conversa parou. As partes interessadas não forneceram nenhum detalhe sobre qual deveria ser o escopo da API, como seria a aparência ou os requisitos detalhados. Ninguém se apresentou para ajudar com as mudanças do Adwaita que eram necessárias, ou com o modo escuro, ou para trabalhar nas ferramentas de controle de qualidade, ou para descobrir os detalhes de implementação. Agora, infelizmente, não temos mais tempo para a libadwaita 1.0 e não há muita esperança de que algo tão complexo esteja pronto nos próximos 4 meses.
Conclusão
Para libadwaita 1.0 e GNOME 42, o trabalho de recolorir widgets provavelmente será concluído. Uma configuração adequada de estilo escuro provavelmente também será implementada até então. As cores de destaque de todo o sistema estão sendo discutidas e analisadas, mas há preocupações relacionadas ao design sobre elas, então é possível que nunca caiam. E não haverá nenhuma “API de Temas” para libadawaita 1.0. Talvez haja um interesse renovado dos fornecedores que querem isso no futuro, mas, dada a história até agora, não vou prender a respiração. Espero ser provado que estou errado.
https://blogs.gnome.org/alatiera/2021/09/18/the-truth-they-are-not-telling-you-about-themes/
Bônus:
A história curta é que GTK3 nunca teve temas, apenas frameworks CSS que algumas distros e usuários têm tratado como temas. E, claro, se você trocar o Bootstrap pelo Tailwind, seu site vai quebrar. Isso geralmente deixa muitas pessoas loucas.