Electron: Considere substituir GTK2 por GTK3 em compilações Linux

Parece-me bem depois de atualizar para o Chrome 47.

O Chrome 47 foi lançado há três dias. :) http://googlechromereleases.blogspot.se/2015/12/stable-channel-update.html

Investigou um pouco, mas ainda não tem certeza de onde colocar a sinalização use_gtk3 ..

@zcbenz ou você pode nos dar dicas de onde colocá-lo?

Não sou especialista nos comportamentos de construção por trás do sistema de compilação do Chromium, mas lendo o bug relacionado ao Chromium lá , deve estar tudo bem se o adicionarmos a variables a common.gypi . A linha relevante está aqui .

Na verdade, estou testando em uma caixa Linux para isso também. Minha caixa de desenvolvimento atual executa o sistema operacional elementar e sempre que um aplicativo Gtk2 é executado, ele exibe um aviso Gtk-Message: Failed to load module "pantheon-filechooser-module" ( Ref ). Se as coisas correrem bem (espero), vamos ver se consigo um RP também. Definitivamente adoraria suas entradas lá.

alguma atualização disso? Como um usuário Atom, gostaria de vê-lo usando GTK3 em vez de GTK2.

@netsgnut funciona bem?

o que o “%” significa?

é a única mudança essa?

diff --git a/common.gypi b/common.gypi
index 7c41c36..d00d7f7 100644
--- a/common.gypi
+++ b/common.gypi
@@ -9,6 +9,7 @@
     'chromeos': 0,
     # Reflects node's config.gypi.
     'component%': 'static_library',
+    'use_gtk3': 1,
     'python': 'python',
     'openssl_fips': '',
     'openssl_no_asm': 1,

Qualquer notícia ? A caixa de diálogo de abertura de arquivo do GTK2 é muito difícil de usar!

@ flying-sheep Ah, desculpe pelo longo silêncio do rádio. Estive comprometido com outros projetos do GitHub, meu mal.

De volta ao nosso caso, era o que eu originalmente acho que deveria funcionar, mas misteriosamente falha em construir aplicativos Gtk3 adequados na minha máquina. No meu caso, minha intenção original é fazer uma compilação do Electron que não emita erro na minha caixa de desenvolvimento (que está executando o Elementary OS Freya). No entanto, parece que construir dessa forma não fará com que o aviso desapareça.

em # 4642, @zcbenz disse:

O sinalizador use_gtk3 só é significativo no lado do Chromium; para habilitar GTK3, precisamos habilitá-lo primeiro no libchromiumcontent e, em seguida, alterar as configurações do link no Electron.

então o que exatamente precisa ser feito?

1. habilite o uso de GTK3 em libchromiumcontent: adicionar um sinalizador em chromiumcontent.gypi será suficiente? isso é importante ou o elétron não usa essa construção de alvo?
2. alterar as configurações de link no Electron: onde fazer isso?

Não sou um especialista neste campo e não tenho certeza se entendi mal o comentário de @zcbenz ; apenas meus 2 centavos.

Em relação às perguntas:

1. Provavelmente não. O libchromiumcontent parece, ao que parece, um monte de scripts que baixa o código fonte do chromium do upstream , patches e reempacotamentos para uso no Atom. Além de alterar um sinalizador em chromiumcontent.gypi como você mencionou, pelo menos as bibliotecas de dependências também são empacotadas corretamente . Veja as instâncias de libgtk2ui .
2. Existem fragmentos no Electron que fazem referência a interfaces de usuário específicas da libgtk2 . Esses apontam para uma dependência dentro do cromo (e / ou derivados). "Links" como no comentário de @zcbenz provavelmente se referem a eles.

O bug de rastreamento no Chromium reflete algum tipo de status do upstream. Um dos comentadores observou:

IIRC, seria necessário construir uma biblioteca libgtk3ui para corresponder a chrome / browser / ui / libgtk2ui /, e ter essas duas bibliotecas trocadas no momento da inicialização.

E, enquanto escrevo, libgtk3ui ainda não existe :( Você também pode dar uma olhada no código em libgtk2ui.

Eu estava entre laptops pessoais depois de postar isto originalmente e tenho usado o MBP emitido pela minha empresa por alguns meses. Mas finalmente tenho minha nova máquina, tempo de inatividade e decidi dar uma olhada nisso. Meu progresso até agora:

Consegui obter o libchromiumcontent para compilar com gtk3, que envolvia o seguinte:

• adicione 'use_gtk3': 1 em chromiumcontent.gypi.
• desabilitou o sysroot comentando manualmente a chamada para install_sysroot() no script / atualização. Nota: Dependendo da versão libchromiumcontent, pode ser necessário definir use_sysroot em chromium/src/build/common.gypi para 'use_sysroot': 0 . Estou assumindo que a abordagem correta no futuro seria mudar para debian_jessie para capacidade de compilação cruzada em compilações.
• executou pkg-config:

pkg-config --cflags gtk+-3.0 wayland-protocols gl egl glib-2.0 x11 gdk-3.0 gmodule-2.0 gthread-2.0 gtk+-unix-print-3.0 libpulse atk --libs gtk+-3.0 wayland-protocols gl egl glib-2.0 x11 gdk-3.0 gmodule-2.0 gthread-2.0 gtk+-unix-print-3.0 libpulse atk && export PKG_CONFIG_PATH=/usr/lib/pkgconfig:/usr/share/pkgconfig

• correu script/update -t x64 && script/build -t x64 && script/create-dist -t x64
• esperou por horas :)

No entanto, infelizmente eu estava um pouco otimista após a conclusão da compilação, pensando que seria um arrastar e soltar para uma compilação de elétrons, mas é claro que não era. Eu acho que o próximo passo é construir um brightray local e quaisquer outros arquivos gyp atualizados para usar minhas libs de sistema e não sysroot.

E em relação à libgtk2ui - estou tendo problemas para localizar a referência de onde li isso (talvez fóruns do gentoo, rastreador de problemas do chromium ou um tópico da comunidade do arch linux) - mas acredito que o Chromium constrói a libgtk2ui independentemente de gtk3 / gtk2 porque os desenvolvedores estavam fazendo o mínimo necessário para que uma compilação com gtk3 funcionasse. Posso estar errado e não sei como isso pode afetar os patches baseados em Electron que foram escritos especificamente para gtk2.

Eu faço uma compilação semanal de chromium-gtk3 para meu navegador pessoal e libgtk2ui ainda está presente e estou supondo que seja usado.

Eu voltarei aqui nos próximos dias e me conectarei ao meu repositório POC com binários pré-construídos e algumas capturas de tela.

Feito e espero ter atom-gtk3 instalado e funcionando em breve!

O maior obstáculo foi debian_wheezy_sysroot sendo usado em libchromiumcontent / electron / brightray. Os mantenedores desses repositórios provavelmente precisarão ter algumas discussões e tomar decisões se devem mudar para o jessie ou possivelmente tornar o sysroot opcional.

No fim de semana, tentarei montar um script de nó ou bash para construir um executável gtk3 de elétron distribuível. Eu não acho que nenhuma solicitação pull que eu faça será aceita, então por enquanto esta provavelmente será a maneira mais eficiente para outros usuários do gtk3 obterem e usarem a compilação. E nas próximas semanas eu posso até tentar obter alguns pacotes AUR para meus colegas usuários do Arch.

Estes foram os avisos gtk3 durante a compilação de elétrons https://gist.github.com/nikolowry/05865698788d66ae0edfea2eb7c7fb0c

@nikolowry Existe uma maneira de manter o sysroot, mas copiar em GTK + 3.x para o sysroot?

@paulcbetts Acho que apenas se Wheezy for atualizado para Jessie (posso estar errado, mas aposto que você ficará em um inferno de dependência se tentar simplesmente inserir gtk3 lá). Além do gtk3, também precisamos das seguintes bibliotecas modernas para o gtk3 construir: wayland-protocols glib-2.0 gdk-3.0 gtk+-unix-print-3.0 .

Parece ótimo @nikolowry , obrigado pelo seu trabalho. O código-fonte está disponível em algum lugar? Eu adoraria ter um PPA pronto para tornar a vida mais fácil para nós, usuários do Ubuntu.

Eu também gostaria de acrescentar que este problema não é apenas uma questão de fornecer widgets modernos. GTK2 não pode ser usado em sistemas HiDPI (pelo menos não com ubuntu 16.04) devido a todos os ícones nos botões e barras de ferramentas serem renderizados extremamente pequenos. Felizmente, no caso do Atom, isso parece afetar apenas a caixa de diálogo de abertura de arquivo, pelo menos até onde posso ver, de modo que o próprio Atom permanece razoavelmente utilizável.

@EiNSTeiN Voltarei em breve a um repositório electron-gtk3 no final do fim de semana.

Primeiro um pouco de história - a principal razão pela qual eu estava determinado a fazer isso funcionar era porque eu uso o Atom como meu driver diário e não aguentava mais ver a caixa de diálogo de arquivo! No entanto, essa construção demorou mais do que o esperado devido a complicações com scripts asar / compiled-cache / npm-not-running-post-install-scripts, mas estou pronto para ir agora.

Eu estava pensando sobre a melhor maneira de fazer isso - então os mantenedores terão uma boa referência (seria difícil coordenar solicitações pull em todos os repo's individuais) e também para que gtk3-would-be-users pudesse começar a funcionar como rapidamente impossível.

Mas eu não estarei fazendo compilações automatizadas, então todos devem estar preparados para tempos de compilação de 4 a 6 horas ou para deixar alguns servidores prontos. Posso acabar lançando ocasionalmente até que essas mudanças sejam refletidas no repositório oficial.

Limitei-me a fazer um repo com elétron como um submódulo e escrever um único script bash para construir elétron com todas as vantagens do gtk3. Então, toda distro pode ter um ponto de partida fácil para, eventualmente, distribuir pacotes até que essas mudanças estejam de fato oficialmente.

E na nota hidpi - meu cmd exec para atom-gtk3 é GTK_THEME=Adwaita:dark GDK_SCALE=2 GDK_DPI_SCALE=.5 /usr/local/share/atom/atom --force-device-scale-factor=1.5 %U . Os sinalizadores de escala GDK também corrigem o tamanho da fonte chromium-gtk3 ui. Aqui estão algumas telas de atom-gtk3 :

https://goo.gl/ydHspu

Oi,

Consegui compilar Electron 1.1.2 com GTK3 no Arch Linux, passando use_gtk3=1 para libchromiumcontent e mudando gtk+-2.0 para gtk+-3.0 em brightray.gyp .

Agora, o aplicativo padrão do Electron funciona sempre que pressiono uma tecla.

Detalhes aqui: https://github.com/tensor5/arch-atom.

O repositório de script de construção:
https://github.com/nikolowry/electron-gtk3

Esperançosamente, tudo estará concluído até o final da semana. É um WIP e ainda não constrói nada significativo.

@EiNSTeiN e @ tensor5 - https://github.com/nikolowry/electron-gtk3 devem ser compilados agora. Observe que ele constrói apenas a versão release menos que você especificamente diga a ele para construir debug e release . verifique o README e abra um problema se algo não estiver funcionando.

@zcbenz existe alguma razão histórica para usar o Debian Wheezy (eu sei que o Chromium gosta de ser compatível com LTS)? Talvez adicionando um sinalizador de construção para usar Jessie / GTK3? Eu poderia trabalhar em uma solicitação de pull adequada se você não se opuser à ideia, caso contrário, você pelo menos tem um script de construção de referência sobre o que é necessário para construir GTK3.

Edit: @ tensor5 você está usando X ou Wayland? Eu sei que as compilações de cromo gtk3 estão travando em eventos de entrada importantes no Wayland.

@nikolowry : sim, eu estava usando o Wayland e, de fato, funciona bem com o X, obrigado. Você sabe se esse problema do Chromium foi discutido em algum lugar?

Encontrou isto: https://bugs.chromium.org/p/chromium/issues/detail?id=615164.

@nikolowry Estamos apenas seguindo as configurações de construção do Chromium, existem muitas distribuições Linux e não podemos testar todas elas, enquanto o Chromium é totalmente testado em todos os lugares, por isso é seguro seguir o Chromium.

Estou bem em adicionar um sinalizador para construir para GTK + 3, e adicionar um link ao seu script de construção também parece bom para mim. Pode ser parte dos tópicos avançados de instrução de construção do Linux .

@zcbenz parece bom - eles têm um script python que pode ser executado e usa Jessie em vez de Wheezy para sysroot, mas acho que é melhor esperar que seja definido como padrão no Chromium upstream.

Em geral, compilar com a distro mais antiga que você pode encontrar é uma coisa boa quando se trata de distribuição de software por causa do controle de versão do glibc ++ - a atualização para Jessie poderia (embora eu considerasse muito mais seguro em geral) pessoas órfãs que trabalharam com Electron em o passado. Encontramos muito esse problema com usuários RHEL

@ tensor5 descobriu como lançar em Wayland. Comentei sobre aquele tíquete do Chromium e atualizei meu repositório gtk3.

Só precisa executar GDK_BACKEND=x11 electron pois o Chromium não se conecta ao módulo XWayland automaticamente.

@nikolowry INCRÍVEL!

Então, se bem entendi, o problema é que GTK3 pensa que o elétron é uma aplicação pura do Wayland, enquanto não é.

@ tensor5 exatamente! GTK3 assume que todos os aplicativos que usam o kit de ferramentas estão prontos para o Wayland (portanto, são responsáveis ​​por carregar o XWayland se necessário).

Eu estava me preparando para ir fundo no código-fonte do Chromium neste fim de semana para descobrir isso, e enquanto tentava gerar alguns logs, tropecei na solução simples via https://fedoraproject.org/wiki/How_to_debug_Wayland_problems.

Chromium e Atom foram meus últimos aplicativos não prontos para Wayland - tão feliz que meu laptop Skylake não travará mais via xrandr quando conectado a vários monitores em modo dpi misto !!!!

Editar: Eu sei que você mantém alguns pacotes AUR também, então você pode querer editar os arquivos da área de trabalho para incluir "env GDK_BACKEND = x11", isso permitirá que os aplicativos sejam executados tanto no X quanto no Wayland e salvará todos os outros muitas dores de cabeça no o futuro!

@nikolowry Já estou trabalhando nisso!

Eventualmente, isso deve ser corrigido na fonte de elétrons, usando um script de iniciador não é a maneira mais elegante.

BTW, o pacote AUR não é meu. Eu mantenho um repositório

@nikolowry O Firefox também é um aplicativo GTK3 que depende do Xwayland, mas funciona bem. Então, eu dei uma olhada: como você pode ver aqui, ele tenta o back-end X11 primeiro e, em seguida, usa o display_name detectado para gdk_display_open .

Provavelmente, algo semelhante pode ser feito no Chromium.

No sistema operacional elementar, precisamos do GTK3 para usar o seletor de arquivos do panteão ou obteremos estes:

Gtk-Message: Failed to load module "pantheon-filechooser-module"

por que não apenas suportar / portar para Qt5-WebEngine ? ele usa o motor de cromo de qualquer maneira, e no Qt tudo parece mais nativo ao contrário do gtk ...

além disso, o qt5 não está quebrado o tempo todo como o gtk3, que muda suas APIs F ** king toda vez, só porque não se preocupa com nada além do desenvolvimento do gnome.

aqui está um ótimo vídeo de apresentação porque gtk é ruim e qt é melhor (2 anos, mas ainda bom e relevante)

O Qt 5.6.x agora está em LTS e sua licença foi alterada para 5.7 , que é muito melhor para usuários / desenvolvedores de código aberto

Eu pessoalmente não entendo por que as pessoas estão usando o gtk fora do gnome, quando ele não foi projetado para isso.

@ahjolinna Na verdade, GTK + também deve ser usado para desenvolvimento de aplicativos fora do Gnome. De qualquer forma, mudar as APIs para QT seria um pesadelo para a equipe do Electron, pois exigiria muitos remendos do Chromium upstream. Não vale a pena.

GTK + 3 _é_ intrinsecamente casado com o GNOME, já que basicamente (?) Todos os desenvolvedores GTK são desenvolvedores GNOME, empregados pela Red Hat.

a quebra da API GTK mencionada acontece porque o chapéu vermelho prioriza o avanço do GNOME. @ahjolinna está certo ao dizer que o Qt5 é mais estável, _mas_ ele apenas fornece acesso limitado à instância do chromium.

a razão também é a estabilidade: o próprio cromo se quebra o suficiente para que eles só possam comprometer seus recursos para manter sua API estável em algumas áreas.

@nikolowry se eu fosse usar https://github.com/nikolowry/electron-gtk3 para construir elétron com suporte gtk3, o que eu precisaria mudar na construção do átomo para construir um átomo-gtk3?

Para aqueles que usam uma construção gtk3, você provavelmente está vendo um texto branco na barra de menu ao usar um tema claro. Este patch resolve o problema.

Vou corrigir os outros avisos de construção do gtk3 nos próximos dias.

O menu no Chromium com Gtk2 não é 'estilo gtk nativo' e é muito feio. A construção do Gtk3 corrigirá isso?

@Menci. Não, a barra de menus com gtk3 é exatamente igual à de gtk2. Você tem razão, não é totalmente nativo, simplesmente as cores do texto e do fundo seguem o tema gtk.
Eu olhei o código nos últimos dias, para ver se isso poderia ser corrigido. Um problema é que o código gtk nativo está escondido atrás de camadas de wrappers de plataforma cruzada. Talvez especialistas em gtk possam ajudar com isso.

@ tensor5 Acho que o menu deve ser implementado nos wrappers de plataforma cruzada. Assim como o menu do OS X é nativo e o código Cocoa nativo também está escondido atrás de camadas de wrappers de plataforma cruzada.

@Menci Claro, é a única maneira que tal patch pode ser aceito.

Também seria bom ter um menu de aplicativos Gnome.

Você pode ver como o LibreOffice fez isso, é de forma semelhante.

Acho que os menus do LibreOffice não são realmente nativos. Eles não têm a sombra projetada e as animações de mostrar / ocultar.

http://caolanm.blogspot.sk/2016/02/native-gtk3-menubar-in-libreoffice.html

Aplicativos GTK + nunca pareceram nativos fora do gnome (e outros spinoffs do gtk), eles sempre pareceram horríveis no KDE, LXQt) e o Unity 8 terá o mesmo problema quando chegar (é baseado em Qt5). A equipe do KDE tentou trabalhar com a equipe do gtk com esse problema, mas eles foram 100% idiotas e não se importam que sua API mude / rompam a cada atualização e isso quebrará (algumas) coisas do KDE como o tema breeze-gtk , que aliás. teve que ser codificado por causa do raciocínio estúpido das equipes gtk. *

por falar nisso. com KDE, LXQt e Unity 8 + Ubuntu Touch e SailfishOS, Qt5 "marketshare" se tornou muito maior que gtk e isso terá um grande efeito pelo menos a longo prazo

PS. sobre o libreoffice, você pode construí-lo sem GTK e tê-lo usando o selecionador de arquivos nativo, isso o que por exemplo o ChakraOS faz, PKGBUILD , por quê? porque é uma distro focada em KDE / Qt que gosta de evitar o uso de GTK tanto quanto possível

editado

* Os desenvolvedores GTK bloquearam o acesso aos motores de tema, que eram usados ​​anteriormente para integração GTK no KDE, então agora a única maneira é tentar o "jeito CSS"

Alguns aplicativos que conheço que usam Qt:
Dropbox, OBS, MEGA, VIber, Wireshark, makemkv, yacreader, masterpdfeditor, editor de vapoursynth, SVP, teamspeak3, mkvtoolnix-gui, hplip, scribus WPS-office ...

outro DE usando Qt5: http://papyros.io/ e https://lumina-desktop.org/

@ahjolinna Acho que você está tentando convencer a turma errada. Se o Chromium não estiver fazendo a troca, duvido muito que o Electron faça a troca. Pedir à equipe Electron para manter este projeto, bem como um fork QT5 do Chromium é pedir demais.

Além disso, esse problema é sobre a substituição de GTK2 por GTK3. Se você quiser que eles considerem uma mudança, crie um novo problema. Caso contrário, está fora do assunto e preenche este tópico com ruído.

@alzadude você tem que editar alguns dos scripts de compilação grunt para que não baixe o elétron pré-construído, edite a versão package.json para corresponder à compilação de elétron que você fez localmente com gtk3 e talvez uma edição python ou duas (desculpe sair memória agora). Não é difícil, mas sempre levo um minuto quando faço uma nova compilação, porque sempre pareço esquecer as poucas etapas que dei na compilação anterior.

Se @ tensor5 está começando a usar gtk3 em seu repositório arch-atom, sugiro tentar isso - caso contrário, voltarei aqui na próxima vez que fizer uma compilação e documentarei as mudanças para você (geralmente faça-as no final de semana)

@nikolowry obrigado, algumas mudanças documentadas seriam ótimas :)

Estou no Fedora, então tentarei incorporar as alterações com base neste copr do Fedora:

https://copr.fedorainfracloud.org/coprs/mosquito/atom/

Este Copr parece ser atualmente a coisa mais próxima de um pacote padrão no Fedora. É baseado nestes arquivos upstream de especificação de rpm:

https://github.com/FZUG/repo/tree/master/rpms/atom

E é mencionado neste bug do Bugzilla:

https://bugzilla.redhat.com/show_bug.cgi?id=1132661

Com base no trabalho existente, eu possivelmente tentaria fazer meu próprio Copr, para compilações gtk3 de Electron e Atom (bifurcando os arquivos de especificação rpm do upstream para incorporar os patches necessários, com base nas alterações documentadas). A menos que outra pessoa me supere, é claro :)

Estou tentando escrever um gentoo ebuild para isso, mas sem sucesso. Ficaria muito grato se alguém me ajudasse a fazer isso.

@ethyl-sorrow Você já deu uma olhada no dev-util / electron, o ebuild que está atualmente na árvore oficial do Gentoo?

@devurandom , sim. É uma versão muito antiga do elétron (0.36.12). Eu o modifiquei para a versão atual (1.3.1), adaptei todos os patches, mas ainda estou tendo um problema de vinculação v8 (muitos símbolos v8 indefinidos).

@ eterna-tristeza

1. Entre em contato com [email protected] , o mantenedor desse pacote.
2. Configure um repo de sobreposição com sua ebuild aqui no GH, talvez possamos resolver isso juntos.

@ eterna-tristeza no Arch Linux nós construímos a última versão do Electron com GTK3 , dê uma olhada nisso.

Algum progresso nisso?

@nikolowry , qual versão de átomo e elétron você está usando em seu atom-gtk3? Percebi que as versões atuais do átomo requerem elétron-0,37 e não podem funcionar com versons atuais de elétron. Estou errado?

@ Eterno-sorrow Atom foi recentemente atualizado para uma versão mais recente do Electron.

https://github.com/atom/atom/blob/efae2e08c3f902149431732cbd550aea09748acc/package.json#L15

Existe alguma maneira de usar o gtk3? Adoraria especialmente para a melhor caixa de diálogo de arquivo.

Já que o archlinux já tem uma construção gtk3, o que falta para ter esse núcleo de elétron?

Acho que eles querem que a mudança aconteça E está oficialmente planejado agora, consulte https://chromium.googlesource.com/chromium/src/+/acc4214c4dece4e70fb53355d557bd45f35965d6/docs/linux_gtk_theme_integration.md#GTK3.

Informações extras, canais de desenvolvimento de chromium / google chrome estão usando gtk 3, então é apenas uma questão de tempo agora.

Confirmado para Chrome 59 em https://bugs.chromium.org/p/chromium/issues/detail?id=79722#c110.

É só uma questão de tempo agora ...

O Chrome 59 foi lançado! : tada:

Agora que o Chrome 59 foi lançado, seria ótimo ver um pré-lançamento do Electron construído com GTK3 para Linux.

O suporte GTK3 agora está no Chromium estável (59), o que significa que em breve será compatível com o Electron ! Como um novato em Linux, não estou muito familiarizado com GTK3. Lendo este tópico e pesquisando no Google, concluo que esta atualização irá melhorar a aparência de menus, janelas, diálogos, etc. Acho que esta pode ser uma atualização digna de um blog, mas adoraria saber mais sobre como essa mudança afeta os usuários.

Eu tenho algumas perguntas:

• Por que você quer suporte GTK3?
• Vejo a "caixa de diálogo de arquivo" muito mencionada neste tópico. O que havia de errado com ele no GTK2 e como ele foi aprimorado no GTK3?
• Esta atualização melhora coisas como desempenho, compatibilidade, etc? Ou apenas UI?
• Que outras melhorias as pessoas podem esperar?
• Quais distros Linux usam GTK (3)?

@zeke :

Por que você quer suporte GTK3? Vejo a "caixa de diálogo de arquivo" muito mencionada neste tópico.

Uma melhoria na qual estou interessado é que os aplicativos Electron executados dentro da sandbox Flatpak agora usarão perfeitamente um portal para um filechooser no host. Isso até usaria o Qt correto se o usuário tiver o portal Qt instalado.

Esta atualização melhora coisas como desempenho, compatibilidade, etc? Ou apenas UI?

Em teoria, o suporte hidpi do Gtk3 pode ser relevante, mas não sei como isso interage com a renderização do Chromium, que contornaria a maior parte disso. Portanto, provavelmente só muda o tema.

Quais distros Linux usam GTK (3)?

Efetivamente, todas as distros possuem Gtk3. Unity, GNOME, MATE, Cinnamon, Budgie e, eventualmente, XFCE usam Gtk3 como seu principal kit de ferramentas para aplicativos.

@zeke

Quais distros Linux usam GTK (3)?

Todas as principais distros do Linux usam GTK3 para sua área de trabalho (shell). Alguns também têm um sabor KDE, mas o padrão para todos eles é GTK3.

Vejo a "caixa de diálogo de arquivo" muito mencionada neste tópico. O que havia de errado com ele no GTK2 e como ele foi aprimorado no GTK3?

Sim, embora os aplicativos GTK2 e GTK3 possam viver juntos no mesmo sistema, os aplicativos GTK3 são mais integrados aos desktops atuais. A caixa de diálogo do Seletor de arquivos é um bom exemplo.

@zeke

Por que você quer suporte GTK3?

Eu valorizo ​​a consistência - a caixa de diálogo do arquivo é bem diferente no GTK 3, os temas costumam ser ligeiramente inconsistentes entre as versões do GTK. Eu também gosto de manter meu sistema mínimo, Atom descartando GTK 2 significará um motivo a menos para ter GTK 2 instalado.

Vejo a "caixa de diálogo de arquivo" muito mencionada neste tópico. O que havia de errado com ele no GTK2 e como ele foi aprimorado no GTK3?

Como acima, para mim o mais importante é a consistência. A caixa de diálogo GTK 3 é considerada inferior por alguns, uma vez que usa a pesquisa recursiva de nome em vez da pesquisa incremental no diretório.

Que outras melhorias as pessoas podem esperar?

Os menus devem usar GTK também, em vez de uma implementação customizada que não parece suportar mnemônicos e pular entre menus adjacentes usando as teclas de seta.

Atom derrubando GTK 2 significará uma razão a menos para ter GTK 2 instalado.

Só para entender o que você está dizendo aqui, @jtojnar : se você tiver uma versão mais recente do Linux que usa GTK3 por padrão, será necessário instalar manualmente o GTK2 para oferecer suporte aos aplicativos que não foram atualizados para o GTK3? Além do Atom (e todos os outros aplicativos Electron), quais outros aplicativos populares têm esse problema?

@zeke A instalação das dependências geralmente é feita automaticamente pelo gerenciador de pacotes de sua distribuição, a instalação do aplicativo GTK 3 também fará o download de libgtk3 e a instalação do aplicativo GTK 2 obterá libgtk2 . Você pode ter ambos instalados com segurança, só que com um SSD com pouco espaço, quero me livrar de todos os pacotes legados que puder.

Por que você quer suporte GTK3?

GTK3 é mais recente e tem suporte para HiDPI.
GTK2 não é mais desenvolvido e não é moderno.

Vejo a "caixa de diálogo de arquivo" muito mencionada neste tópico. O que havia de errado com ele no GTK2 e como ele foi aprimorado no GTK3?

Não sei sobre este.

Esta atualização melhora coisas como desempenho, compatibilidade, etc? Ou apenas UI?

Diz-se que GTK3 utiliza melhor alguns recursos de CPU e RAM, mas não tenho certeza do contrário. No entanto, seria uma grande atualização da IU.

Que outras melhorias as pessoas podem esperar?

Melhor suporte para temas.

Quais distros Linux usam GTK (3)?

Todas as distros possuem GTK3 em seus repositórios.
Muitos dos principais ambientes de desktop usam GTK3, como Gnome 3, Budgie, Deepin, MATE e soon (tm) XFCE também.

Um pré-requisito para isso é o Chromium 59, que há uma solicitação de pull para # 9946.

A conclusão principal do

Vejo a "caixa de diálogo de arquivo" muito mencionada neste tópico. O que havia de errado com ele no GTK2 e como ele foi aprimorado no GTK3?

GTK2 em comparação com GTK3 pode ser melhor explicado como versões anteriores do Windows ou macOS, em que a IU tinha uma aparência visual diferente (diferenças de layout / funcionalidade de itens como navegadores de arquivos). Se você executar o Windows 10 e receber uma caixa de diálogo de arquivo semelhante ao Windows Vista ou XP, ela parecerá deslocada e possivelmente não terá alguns recursos / UX.

Em um ambiente de área de trabalho (DE) como o KDE, isso ainda cria uma caixa de diálogo GTK3 em vez do kit de ferramentas mais comum para esse DE, o Qt. Portanto, ainda há alguma inconsistência aí, mas é melhor do que GTK2.

Aqui estão alguns exemplos no KDE com o tema padrão do Breeze:

GTK2 Dialog com aplicativos Electron atuais - GitKraken:

Diálogo GTK3 - Combinar:

Diálogo Qt - Kate:

Diálogo Mono / .NET (?) - BundleModder - Incomum no Linux, os aplicativos Java também podem usar um kit de ferramentas incomum:

Como você pode ver, a consistência do estilo é bastante diferente entre os diferentes kits de ferramentas de IU. Isso pode ser confuso para um usuário casual por que eles são diferentes, levando você a se perguntar se eles têm o mesmo propósito ou frustração com os detalhes de navegação / apresentação serem diferentes entre eles (GTK você pode clicar duas vezes em, enquanto o Qt pode ser configurado para um único clique na navegação da pasta) ou apenas vendo a falta de consistência como pouco profissional.

O Gnome (DE focado em GTK) é capaz de lidar com isso melhor do que o KDE (DE focado em Qt) com consistência entre GTK3 e Qt, já que o kit de ferramentas do Qt é projetado para se integrar bem às plataformas, dando uma sensação / experiência nativa. Os desenvolvedores de GTK estão relutantes em oferecer suporte a seu kit de ferramentas em DEs diferentes do Gnome, apesar dos desenvolvedores de KDE quererem contribuir com o código para resolver o problema em seu DE. Se o usuário não estiver usando aplicativos mais antigos que usam GTK2 ou kits de ferramentas incomuns, ele terá uma experiência melhor.

Freqüentemente, você encontrará uma mistura de aplicativos GTK e Qt quando um kit de ferramentas não tem uma oferta tão forte quanto os outros aplicativos equivalentes de kits de ferramentas, para alguns usuários, usar apenas um único aplicativo de kits de ferramentas é viável (KaOS é uma distro que atende ao Qt5 experiência, com aplicativos GTK opcionais como o Chrome disponíveis). Com a popularidade dos aplicativos Electron, evitar GTK nem sempre é desejável.

Por que você quer suporte GTK3?

Consistência, a caixa de diálogo de arquivo é a que mais se destaca para mim como usuário do KDE.

Esta atualização melhora coisas como desempenho, compatibilidade, etc? Ou apenas UI?
Que outras melhorias as pessoas podem esperar?

Embora eu não saiba muito sobre FlatPak (aplicativos em sandbox, distro-agnósticos, uma espécie de Docker / contêineres para aplicativos de GUI), acho que GTK3 tem uma história melhor do que GTK2, incluindo integração com o DE (o tema FlatPak é outro para consistência, GTK3 no FlatPak recentemente obteve suporte a temas, outros kits de ferramentas também precisam ser adicionados). FlatPak como mencionado também pode aliviar os problemas de diálogo de arquivo por meio de seu suporte de portais.

Eu não sei muito sobre GTK2 vs GTK3 pessoalmente, mas a história de HiDPI será melhor para GTK3, eu imagino (GTK2 pode nem ter isso?). Suponho que o suporte a temas seja melhor, ou pelo menos você terá mais chances de obter temas para GTK3 do que 2, especialmente no futuro. No Gnome, a caixa de diálogo do arquivo pode ser um pouco diferente com as decorações do lado do cliente (CSD) melhorando a experiência do usuário para esses usuários. No KDE, acho que o suporte GTK3 pode funcionar melhor com o recurso Menu Global (ainda WIP, macOS como a barra de menus em vez de estar vinculado à janela de aplicativos).

Quais distros Linux usam GTK (3)?

A maioria das distros modernas está usando GTK3 ou dando suporte até onde eu sei. GTK2 é bastante antigo. Se você estiver usando aplicativos Chrome ou Electron, você está usando GTK (provavelmente uma mistura de 2/3, mas inclinado mais para 3).

@polarateno , você não mencionou que o suporte GTK3 permite adicionar suporte a Wayland no futuro, enquanto o GTK2 não.

A compilação JFYI Chromium GTK2 está danificada no último 60.0.3112.90 estável e no beta 61.0.3163.31.
Mas funciona no master mais recente.

E aliás, ele não é mais mantido oficialmente.
https://groups.google.com/a/chromium.org/d/msg/chromium-dev/iO3qzex6oYA/Q-i4Cie3BwAJ

Feedback incrível sobre as virtudes do GTK3, a todos. Obrigado pela sua contribuição.

Infelizmente, parece que a atualização GTK3 não vai pousar no Electron 1.8 com Chrome 59. No momento, está bloqueando a compilação, então teremos que esperar até o próximo aumento do Chromium para 61 (estamos pulando 60) antes que o GTK3 seja compatível em Electron.

Isso está correto, @alexeykuzmin?

@zeke , você tem alguma estimativa aproximada de quando a colisão com o cromo 61 vai acontecer? Gostaríamos de planejar nossa mudança para componentes da web ES6 nativos para nos alinhar com essa versão. Historicamente, os solavancos ocorrem cerca de um mês após o lançamento?

@zeke
Sim, tivemos alguns problemas com o GTK3 no branch Chromium 59.
Mas devemos mudar de GTK2 para GTK3 na próxima atualização do Chromium 61.

@cpoole , não temos uma estimativa de quando o Chromium 61 https://github.com/electron/libchromiumcontent/pull/335. Nosso objetivo é eventualmente estar mais em sintonia com os lançamentos do Chromium. Algumas pessoas incríveis da Microsoft ( @tonyganch , @cifratila , @alexeykuzmin , @alespergl , outros?) Têm ajudado nesse processo, que está liberando a equipe Electron do GitHub para se concentrar em melhorar a CI e suavizar o processo de lançamento do Electron. Estou otimista :)

Por que você quer suporte GTK3?

@deikatsuo Que navegador é esse? Parece que o Chrome e a Epifania tiveram um bebê ...

@mdsitton epiphany 👍

Alguma novidade sobre isso?

@ ziggy42 já deve estar lá no último chromium 61 (https://github.com/electron/electron/pull/10213). Eu acho que é apenas uma questão de fundir no master e fazer um lançamento em algum ponto.

Mal posso esperar, esses seletores de arquivos feios queimam meus olhos: fogo:

Essa mudança permitirá CSS em aplicativos Electron?

Então, o cromo 61 é mesclado, o gtk3 virá com ele?

Electron agora está usando GTK3 no branch master, será enviado na próxima versão secundária / principal.

@ahjolinna

Obrigado por gastar um pouco de sanidade nesta discussão.

Você pode estar realmente interessado no KaOS, que já foi mencionado.
Ele é mantido pela própria pessoa que tornou o Chakra excelente por vários anos, IMHO.

@tudo

GTK + 3 foi lançado quando?

7 anos atrás.

Deixe isso derreter na boca por um tempo.

E um monte de projetos de software ainda estão parados no 2.
Já que portar é um prazer ..

XFCE, Mate e muitos outros levaram 6 anos para portar o código.
Outros projetos mudaram completamente de GTK para Qt dentro de 2.

E sim: GTK + é desenvolvido pelo GNOME, até o repo está lá.
É - por natureza e definição - desenvolvido para GNOME e nada mais.

Qt é desenvolvido para integração verdadeira e nativa em várias plataformas.

Elétron é o quê?

Uma loja GNOME?

Agradável.

Pensamento inteligente.

É o mesmo que na programação imperativa e funcional, bem como em tantos outros aspectos aqui nesta cena: Software redundante, antigo e desatualizado é frequentemente tratado como uma droga viciante, o que o torna um.

E um software novo, inteligente e inovador é tratado por equívocos e pura ignorância.

10, 12 projetos mudaram de GTK + para Qt enquanto eu não conheço um único caso, onde aconteceu o contrário.

Deixe isso derreter na sua língua novamente: Isso significa uma reescrita completa de todo o código de interface do usuário integrado.
Profundamente aninhado, frequentemente.

O que significa que eles preferem isso, em comparação com uma grande atualização de sua ferramenta existente.
E todos estão felizes com essa decisão, até hoje.

Pergunte a eles.

Antes de seguir o rebanho sem considerar alternativas.

@ahjolinna postou para você um vídeo de uma dessas pessoas, VLC, Wireshark, LXQt e outros projetos de software notáveis ​​também são anteriormente baseados em GTK.

GTK é usado apenas no Chromium como uma ligação para Aura e isso apenas em Linux / freeBSD / Solaris e assim por diante:
As compilações do Windows e do macOS são gratuitas.

:piscadela:

Embora eu consiga seus pontos @ShalokShalom , não precisa ser rude, o Electron segue o que é entregue pela equipe do Chromium.

O botão do garfo está no topo, fique à vontade.

Sim, isso era desnecessariamente abrasivo.

Mas eu concordo. GTK tem muitas quebras desnecessárias que causam dor, Qt teria sido uma escolha melhor

• IF QtWebEngine fornece acesso suficiente à instância de cromo subjacente
• SE o QtWebEngine rastreia o Chromium mais recente com rapidez suficiente

Eu sugiro que movamos a discussão para um local mais apropriado. @ShalokShalom , que tal você abrir uma nova edição aqui e descrever o problema de uma maneira mais civilizada do que agora?

VLC , Wireshark, LXQt e outros projetos de software notáveis ​​também são anteriormente baseados em GTK.

Isso não é verdade. O VLC estava usando wxWidgets antes do Qt, não GTK: https://wiki.videolan.org/WxWidgets_Interface/

Parece-me que o pessoal do GTK já reconheceu há algum tempo que não comunicou a quebra e o versionamento bem o suficiente na série 3.x e se esforçará mais no futuro com estabilidade melhor e mais clara a longo prazo, conforme pode ser lido em https: / /blog.gtk.org/2016/09/01/versioning-and-long-term-stability-promise-in-gtk/.

Eu também diria que Qt e GTK não podem ser comparados um a um devido à história, apoio e objetivos diferentes e, na minha opinião, ambos têm prós e contras dependendo do seu ponto de vista.

Afirmar que GTK é feito para e apenas para o projeto GNOME também é, na minha opinião, uma declaração geral injusta.

ha! eu realmente não sabia sobre esses planos. parece que finalmente aprenderam. vamos esperar que eles comecem a considerar qualquer alteração significativa no CSS como uma alteração realmente significativa.

a última coisa que ouvi foi o ... humm ... excêntrico GTK 4.0 não é GTK 4 . então finalmente chegamos a algo quase tão bom quanto o nunca! eles se saem quase tão bem quanto o Qt há 20 anos! 😁

Devemos ver o Electron com suporte GTK3 nativo por padrão em breve com base nesta postagem do Twitter :

Electron 2.0.0-beta.1 é lançado com Chromium e Node.js atualizados, compras no aplicativo do macOS, suporte GTK3 para Linux e muito mais.

sim. O verdadeiro trabalho para isso foi feito pelos autores do Chromium e Electron conseguiu isso através da atualização do Chromium no Electron 2.0.0.

Além disso, o código do próprio Electron foi GTK3ificado em https://github.com/electron/electron/pull/11879

Sim, isso era desnecessariamente abrasivo.
Mas eu concordo. GTK tem muitas quebras desnecessárias que causam dor, Qt
teria sido uma escolha melhor
IF QtWebEngine fornece acesso suficiente à instância de cromo subjacente
SE o QtWebEngine rastreia o Chromium mais recente com rapidez suficiente

Bem, este é o problema principal. As pessoas consideram o que é mais rápido de implementar para elas, o que é bom, enquanto muitas vezes esquecem que a implementação real para fazê-lo funcionar é algo muito diferente da manutenção de longo prazo.

É claro, do meu ponto de vista, que as questões mencionadas podem ser resolvidas.

Depois de comparar a quantidade de codificadores que realmente trabalham em portas GTK3 e aqueles que transportam todo o seu código de IU em um novo kit de ferramentas, você pode ver como a diferença é incrível. Acho que já postei um vídeo sobre isso, chamado 'Do GTK ao Qt: Uma jornada estranha.'

Por que focar em software desatualizado, simplesmente porque parece pronto para uso, em vez de hackear o suporte no Qt?

É o dogma "Eu uso o que parece estar pronto", que ignora completamente as decisões de longo prazo. Sim, pode parecer que exige um pouco mais de esforço em primeiro lugar, enquanto vocês certamente se beneficiam do kit de ferramentas moderno, uma vez implementado.

Também não é tão drástico que o QtWebEngine não siga o Chrome tão rapidamente:
É rápido o suficiente e o Qupzilla prova que você pode fazer coisas incríveis com ele - especialmente em um ambiente adequado, como o KaOS.

Você realmente acha que precisa de 'mais acesso ao Chromium subjacente' e que 'QtWebEngine não segue o Chromium com rapidez suficiente', uma vez que o Qupzilla e outros softwares comprovam fornecer um software incrível, mantido por um único codificador?

Você acha que precisa de mais acesso e acompanhamento mais rápido como um navegador da Web completo no Electron? Como assim?

Agora, você se senta nesta pilha de software desajeitada em tantos projetos e pequenas equipes conseguem portar 40-60% de seu código profundamente aninhado para Qt de forma rápida e eficiente;

Algo que eles não conseguiram fazer do GTK 2 ao GTK 3, o que é incrível. Como disse: a maioria dos projetos levou de 6 a 7 anos para atualizar uma versão principal

E quase todo mundo parece ignorar isso? É tão triste que, em uma comunidade inicialmente científica, as decisões primitivas continuem a se espalhar.

Paz :)

@ShalokShalom , o que você quer dizer com "software desatualizado"? GTK +? Alguma razão para você dizer isso?

Por favor, pare com este spam Qt, este é um problema sobre a porta GTK 3. Se você sentir a necessidade de convencer os mantenedores a mudar para o Qt, abra um problema separado. Quero receber notícias sobre o progresso da implementação, não mensagens de fanboys do Qt.

Bloqueando esta conversa devido ao excesso de discussão fora do tópico.

O bloqueio apenas resolve um sintoma, mas é uma solução rápida razoável, uma vez que a mudança para GTK3 está terminando e não há muito o que discutir sobre o tópico deste problema de mudança de GTK2 para GTK3.