Electron: Envisagez de remplacer GTK2 w GTK3 dans les versions Linux

Cela me semble bien après la mise à niveau vers Chrome 47.

Chrome 47 est sorti il ​​y a trois jours. :) http://googlechromereleases.blogspot.se/2015/12/stable-channel-update.html

J'ai creusé un peu mais je ne sais toujours pas où mettre l'indicateur use_gtk3 ..

@zcbenz ou pouvez-vous nous

Je ne suis pas un expert des comportements de construction derrière le système de construction pour Chromium, mais en lisant le bogue lié à Chromium , cela devrait aller de l'ajouter au variables à common.gypi . La ligne correspondante est ici .

En fait, je teste aussi sur une machine Linux pour cela. Ma boîte de développement actuelle exécute Elementary OS , et chaque fois qu'une application Gtk2 est exécutée, elle affiche un avertissement Gtk-Message: Failed to load module "pantheon-filechooser-module" ( Ref ). Si les choses se passent bien (espérons-le), voyons si je peux aussi obtenir un PR. J'adorerais certainement vos contributions là-bas cependant.

Une mise à jour pour ceci? En tant qu'utilisateur d'atom, j'aimerais le voir utiliser GTK3 au lieu de GTK2.

@netsgnut ça marche bien ?

que signifie le « % » ?

est le seul changement celui-ci ?

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,

Des nouvelles ? La boîte de dialogue d'ouverture de fichier GTK2 est assez pénible à utiliser !

@flying-sheep Ah, désolé pour le long silence radio. Été engagé dans d'autres projets hors GitHub, mon mauvais.

Revenons à notre cas, c'était ce que je pensais à l'origine qui devrait fonctionner, mais mystérieusement, il ne parvient pas à créer des applications Gtk3 appropriées sur ma boîte. Dans mon cas, mon intention initiale est de créer une version Electron qui n'émettrait pas d'erreur sous ma boîte de développement (qui exécute Elementary OS Freya). Cependant, il semble que construire de cette façon ne fera pas vraiment disparaître l'avertissement.

dans le n° 4642, @zcbenz a dit :

Le drapeau use_gtk3 n'a de sens que du côté de Chromium, pour activer GTK3, nous devons d'abord l'activer dans libchromiumcontent, puis modifier les paramètres de lien dans Electron.

alors que faut-il faire exactement ?

1. activer l'utilisation de GTK3 dans libchromiumcontent : l'ajout d'un indicateur dans chromiumcontent.gypi sera-t-il suffisant ? est- ce important ou l'électron n'utilise-t-il pas cette cible ?
2. modifier les paramètres du lien dans Electron : où faire cela ?

Je ne suis pas un expert dans ce domaine, et je ne sais pas si j'ai mal compris le commentaire de

Concernant les questions :

1. Probablement pas. libchromiumcontent semble, à première vue, un tas de scripts qui télécharge la source de chrome en amont , des correctifs et des reconditionnements à utiliser dans Atom. En plus de changer un indicateur sur chromiumcontent.gypi comme vous l'avez mentionné, au moins les bibliothèques de dépendances sont également empaquetées correctement . Voir les instances de libgtk2ui .
2. Il existe des fragments dans Electron qui font référence à des interfaces utilisateur spécifiques à libgtk2 . Ceux-ci indiquent une dépendance au sein du chrome (et/ou de ses dérivés). Les "liens" comme dans le commentaire de @zcbenz font probablement référence à ceux-ci.

Le bug de suivi sur Chromium reflète une sorte de statut en amont. L'un des commentateurs note :

IIRC, il faudrait construire une bibliothèque libgtk3ui pour correspondre à chrome/browser/ui/libgtk2ui/, et faire basculer ces deux bibliothèques au démarrage.

Et, au moment de la rédaction, libgtk3ui n'existe pas encore :( Vous pouvez également consulter le code sur libgtk2ui.

J'étais entre des ordinateurs portables personnels après avoir publié ce message pour la première fois et j'utilisais depuis quelques mois le MBP émis par mon entreprise. Mais j'ai enfin ma nouvelle machine, un temps d'arrêt et j'ai décidé de tenter le coup. Mes progrès jusqu'à présent:

J'ai pu obtenir libchromiumcontent à construire avec gtk3, cela impliquait ce qui suit :

• ajoutez 'use_gtk3': 1 dans chromiumcontent.gypi.
• désactivé sysroot en commentant manuellement l'appel pour install_sysroot() dans le script/la mise à jour. Remarque : Selon la version de libchromiumcontent, vous devrez peut-être définir use_sysroot dans chromium/src/build/common.gypi sur 'use_sysroot': 0 . Je suppose que la bonne approche à l'avenir serait de passer à debian_jessie pour la capacité de compilation croisée dans les builds ?
• a exécuté 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

• couru script/update -t x64 && script/build -t x64 && script/create-dist -t x64
• attendu des heures :)

Cependant, j'étais malheureusement un peu trop optimiste une fois la construction terminée, pensant qu'il s'agissait d'un glisser-déposer pour une construction d'électrons, mais bien sûr, ce n'était pas le cas. Je pense que la prochaine étape consiste à créer un Brightray local et à mettre à jour tous les autres fichiers gyp pour utiliser mes bibliothèques système et non sysroot.

Et en ce qui concerne la libgtk2ui - j'ai du mal à localiser la référence où j'ai lu ceci (peut-être les forums gentoo, le suivi des problèmes de chrome ou un fil de discussion de la communauté arch linux) - mais je pense que Chromium construit la libgtk2ui indépendamment de gtk3/gtk2 parce que les développeurs faisaient le strict minimum pour qu'une version avec gtk3 fonctionne. Je peux me tromper et je ne sais pas comment cela pourrait affecter les correctifs basés sur Electron qui ont été écrits spécifiquement pour gtk2.

Je fais une compilation hebdomadaire de chromium-gtk3 pour mon navigateur personnel et libgtk2ui est toujours présent et je suppose qu'il est utilisé.

Je reviendrai ici, espérons-le, dans les prochains jours et créerai un lien vers mon référentiel POC avec des binaires prédéfinis et quelques captures d'écran.

C'est fait et j'espère que atom-gtk3 bientôt opérationnel !

Le plus gros obstacle était l'utilisation de debian_wheezy_sysroot dans libchromiumcontent/electron/brightray. Les responsables de ces dépôts auront probablement besoin d'avoir des discussions et de décider s'ils doivent passer à Jessie ou éventuellement rendre sysroot facultatif.

Au cours du week-end, je vais essayer de mettre en place un script node ou bash pour créer un exécutable electron gtk3 distribuable. Je ne pense pas qu'aucune demande de tirage que je ferais sera acceptée, donc pour l'instant, ce sera probablement le moyen le plus efficace pour les autres utilisateurs de gtk3 d'obtenir et d'utiliser la version. Et au cours des prochaines semaines, je pourrais même essayer d'obtenir des packages AUR pour mes collègues utilisateurs d'Arch.

Ce sont les avertissements gtk3 lors de la construction électronique https://gist.github.com/nikolowry/05865698788d66ae0edfea2eb7c7fb0c

@nikolowry Existe-t-il un moyen pour nous de conserver sysroot mais de copier en GTK + 3.x dans le sysroot?

@paulcbetts Je pense que si Wheezy est mis à niveau vers Jessie (je peux me tromper mais je serais prêt à parier que vous vous retrouveriez dans l'enfer de la dépendance si vous essayiez simplement d'y glisser gtk3). En plus de gtk3, nous avons également besoin des bibliothèques modernes suivantes pour la compilation de gtk3 : wayland-protocols glib-2.0 gdk-3.0 gtk+-unix-print-3.0 .

Ça a l' air génial

Je voudrais également ajouter que ce problème n'est pas seulement une question de fournir des widgets modernes. GTK2 n'est pas utilisable sur les systèmes HiDPI (du moins pas avec Ubuntu 16.04) car toutes les icônes des boutons et des barres d'outils sont rendues extrêmement petites. Heureusement, dans le cas d'Atom, cela semble affecter uniquement la boîte de dialogue d'ouverture de fichier, du moins pour autant que je puisse le voir, donc Atom lui-même reste assez utilisable.

@EiNSTeiN Je reviendrai sous peu à un dépôt electron-gtk3 d'ici la fin du week-end.

Une petite histoire d'abord - la principale raison pour laquelle j'étais déterminé à faire fonctionner cela était parce que j'utilise Atom comme pilote quotidien et que je ne supportais plus de voir la boîte de dialogue du fichier ! Cependant, cette version a pris plus de temps que prévu en raison de complications avec asar/compiled-cache/npm-not-running-post-install-scripts, mais je suis prêt à partir maintenant.

J'avais réfléchi à la meilleure façon de le faire - les responsables auront donc une bonne référence (ce serait difficile de coordonner les demandes d'extraction dans tous les référentiels individuels) et aussi pour que gtk3-would-be-users puisse être opérationnel en tant que vite impossible.

Mais je ne ferai pas de builds automatisés, donc tout le monde doit être préparé pour des temps de build de 4 à 6 heures ou pour préparer certains serveurs. Je pourrais finir par faire la publication occasionnelle jusqu'à ce que ces changements soient reflétés dans le référentiel officiel.

Je me suis concentré sur la création d'un dépôt avec l'électron comme sous-module et l'écriture d'un seul script bash pour construire l'électron avec toute la bonté gtk3. Ensuite, chaque distribution peut avoir un point de départ facile pour éventuellement distribuer des packages jusqu'à ce que ces changements soient réellement en vigueur.

Et sur la note hidpi - mon cmd exec pour atom-gtk3 est GTK_THEME=Adwaita:dark GDK_SCALE=2 GDK_DPI_SCALE=.5 /usr/local/share/atom/atom --force-device-scale-factor=1.5 %U . Les indicateurs d'échelle GDK corrigent également la taille de la police chromium-gtk3 ui. Voici quelques screens de atom-gtk3 :

https://goo.gl/ydHspu

Salut,

J'ai pu compiler Electron 1.1.2 avec GTK3 sur Arch Linux, en passant use_gtk3=1 à libchromiumcontent et en changeant gtk+-2.0 en gtk+-3.0 dans brightray.gyp .

Désormais, l'application par défaut d'Electron se bloque chaque fois que j'appuie sur une touche.

Détails ici : https://github.com/tensor5/arch-atom.

Le dépôt du script de compilation :
https://github.com/nikolowry/electron-gtk3

J'espère qu'il sera terminé d'ici la fin de la semaine. C'est un WIP et ne construit encore rien de significatif.

@EiNSTeiN et @tensor5 - https://github.com/nikolowry/electron-gtk3 devraient être construits maintenant. Notez qu'il ne construit que la version release moins que vous ne lui disiez spécifiquement de construire à la fois debug et release . consultez le fichier README et ouvrez un problème si quelque chose ne fonctionne pas.

@zcbenz y a-t-il une raison historique à l'utilisation de Debian Wheezy (je sais que Chromium aime être compatible LTS) ? Peut-être ajouter un indicateur de construction pour utiliser Jessie/GTK3 ? Je pourrais travailler sur une pull request appropriée si vous n'êtes pas opposé à l'idée, sinon vous avez au moins un script de construction de référence sur ce qu'il faut pour que GTK3 se construise.

Edit : @ tensor5 utilisez-vous X ou Wayland ? Je sais que les versions de chrome gtk3 plantent sur des événements d'entrée clés dans Wayland.

@nikolowry : oui j'utilisais Wayland, et effectivement ça marche bien avec X, merci. Savez-vous si ce problème de chrome a été discuté quelque part ?

Trouvé ceci : https://bugs.chromium.org/p/chromium/issues/detail?id=615164.

@nikolowry Nous ne faisons que suivre les configurations de construction de Chromium, il existe de nombreuses distributions Linux et nous ne sommes pas en mesure de toutes les tester, alors que Chromium est entièrement testé partout, il est donc sûr de suivre Chromium.

Je suis bon d'ajouter un indicateur à construire pour GTK+3, et l'ajout d'un lien vers votre script de construction me convient également. Cela peut faire partie des sujets avancés de l'instruction de construction Linux .

@zcbenz sonne bien - ils ont un script python que l'on pourrait exécuter qui utilise Jessie au lieu de Wheezy pour sysroot, mais je suppose qu'il vaut mieux attendre qu'il soit défini par défaut dans Chromium en amont.

En général, construire contre la plus ancienne distribution que vous pouvez trouver est une bonne chose quand il s'agit de distribuer des logiciels en raison de la gestion des versions glibc++ - la mise à niveau vers Jessie pourrait (bien que je le considère de manière plus sûre en général) des orphelins qui avaient travaillé dans Electron le passé. Nous avons beaucoup rencontré ce problème avec les utilisateurs de RHEL

@ tensor5 a compris comment se lancer dans Wayland. J'ai commenté ce ticket Chromium et mis à jour mon référentiel gtk3.

Il suffit d'exécuter GDK_BACKEND=x11 electron car Chromium ne se connecte pas automatiquement au module XWayland.

@nikolowry IMPRESSIONNANT !

Donc, si je comprends bien, le problème est que GTK3 pense que l'électron est une pure application Wayland, alors que ce n'est pas le cas.

@ tenseur5 exactement ! GTK3 suppose que toutes les applications utilisant la boîte à outils sont prêtes pour Wayland (donc responsable du chargement de XWayland si nécessaire).

Je me préparais à entrer dans le code source de Chromium ce week-end pour le comprendre, et alors que j'essayais de générer des journaux, je suis tombé sur la solution simple via https://fedoraproject.org/wiki/How_to_debug_Wayland_problems.

Chromium et Atom étaient mes dernières applications non prêtes pour Wayland - si heureux que mon ordinateur portable Skylake ne plante plus via xrandr lorsqu'il est connecté à plusieurs moniteurs en mode dpi mixte !!!!

Edit : je sais que vous maintenez également certains packages AUR, vous souhaiterez donc peut-être modifier les fichiers du bureau pour inclure "env GDK_BACKEND=x11", cela permettra aux applications de s'exécuter à la fois dans X et Wayland et d'éviter à tout le monde de nombreux maux de tête. l'avenir!

@nikolowry j'y suis déjà !

Finalement, cela devrait être corrigé dans la source d'électrons, l'utilisation d'un script de lancement n'est pas la manière la plus élégante.

BTW le paquet AUR n'est pas le mien. Je maintiens un référentiel

@nikolowry Firefox est également une application GTK3 qui s'appuie sur Xwayland, mais elle fonctionne bien. J'y ai donc jeté un coup d'œil : comme vous pouvez le voir ici, il essaie d'abord le backend X11, puis utilise le display_name détecté pour gdk_display_open .

Probablement une chose similaire peut être faite dans Chromium.

Sur le système d'exploitation élémentaire, nous avons besoin de GTK3 pour utiliser le sélectionneur de fichiers pantheon, ou nous aurons ceci :

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

pourquoi ne pas simplement supporter/porter vers Qt5-WebEngine ? il utilise de toute façon le moteur de chrome, et sur Qt tout semble beaucoup plus natif contrairement à gtk...

De plus, qt5 n'est pas cassé tout le temps comme gtk3 qui change ses API F ** king à chaque fois simplement parce qu'ils ne se soucient de rien d'autre que du développement de gnome.

voici une excellente présentation vidéo pourquoi gtk est mauvais et qt est meilleur (2 ans mais toujours bon et pertinent)

Qt 5.6.x est maintenant en LTS et leur licence a changé avec 5.7 , c'est bien mieux pour les utilisateurs/développeurs open source

Personnellement, je ne comprends pas pourquoi les gens utilisent gtk en dehors de gnome, alors qu'il n'est pas conçu pour cela.

@ahjolinna En fait, GTK+ est également destiné à être utilisé pour le développement d'applications en dehors de Gnome. Quoi qu'il en soit, changer les API en QT serait un cauchemar pour l'équipe Electron car cela nécessiterait beaucoup de correctifs de la part de Chromium en amont. Cela n'en vaut pas la peine.

GTK+3 _est_ intrinsèquement marié à GNOME, puisque fondamentalement (?) Tous les développeurs GTK sont des développeurs GNOME, employés par Red Hat.

la rupture de l'API GTK mentionnée se produit parce que le chapeau rouge donne la priorité à l'avancement de GNOME. @ahjolinna a raison de dire que Qt5 est plus stable, _mais_ il ne fournit qu'un accès limité à l'instance de chrome.

la raison en est également la stabilité : le chrome lui-même se casse suffisamment pour qu'ils ne puissent engager leurs ressources que pour maintenir leur API stable dans certains domaines.

@nikolowry si je devais utiliser https://github.com/nikolowry/electron-gtk3 pour construire un électron avec le support gtk3, que devrais-je changer dans la construction de l'atome afin de construire un atome-gtk3 ?

Pour ceux qui utilisent une version gtk3, vous voyez probablement du texte blanc dans la barre de menu lorsque vous utilisez un thème léger. Ce patch résout le problème.

Je vais corriger les autres avertissements de build gtk3 dans les prochains jours.

Le menu dans Chromium avec Gtk2 n'est pas "style gtk natif", et est très moche. Le build Gtk3 résoudra-t-il ce problème ?

@Menci. Non, la barre de menu avec gtk3 ressemble exactement à celle de gtk2. Vous avez raison, ce n'est pas complètement natif, simplement les couleurs du texte et de l'arrière-plan suivent le thème gtk.
J'ai regardé le code ces derniers jours, pour voir si cela pouvait être corrigé. Un problème est que le code gtk natif est caché derrière des couches de wrappers multiplateformes. Peut-être que les experts de gtk peuvent vous aider.

@ tensor5 Je pense que le menu devrait être implémenté dans les wrappers multiplateformes. Tout comme le menu d'OS X est natif et le code Cocoa natif est également caché derrière des couches de wrappers multiplateformes.

@Menci Bien sûr, c'est la seule façon dont un tel correctif pourrait être accepté.

Ce serait également bien d'avoir un menu d'application Gnome.

Vous pouvez regarder comment LibreOffice l'a fait, c'est de la même manière.

Je pense que les menus de LibreOffice ne sont pas vraiment natifs. Ils n'ont pas l'ombre portée et les animations pour afficher/masquer.

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

Les applications GTK+ n'ont jamais semblé natives en dehors de gnome (et d'autres retombées de gtk), elles ont toujours l'air horribles sur KDE, LXQt) et Unity 8 aura le même problème à son arrivée (basé sur Qt5). L'équipe KDE a essayé de travailler avec l'équipe gtk avec ce problème, mais ils ont été des abrutis complets à 100% et ils se moquent que leur API change/casse à chaque fichue mise à jour et cela va casser (certains) trucs de KDE comme le thème brise-gtk , qui d'ailleurs. a dû être codé en dur à cause du raisonnement stupide des équipes gtk.*

d'ailleurs. avec KDE, LXQt et Unity 8 + Ubuntu Touch et SailfishOS, la "part de marché" de Qt5 est devenue bien plus importante que gtk et cela aura un impact énorme au moins à long terme

PS. à propos de libreoffice, vous pouvez le construire sans GTK et l'avoir en utilisant le sélecteur de fichiers natif, c'est ce que fait par exemple ChakraOS, PKGBUILD , pourquoi ? parce que sa distribution axée sur KDE/Qt aime éviter autant que possible d'utiliser GTK

édité

* Les développeurs GTK ont bloqué l'accès aux moteurs de thèmes, qui étaient utilisés auparavant pour l'intégration GTK dans KDE, donc maintenant le seul moyen est d'essayer la "voie CSS"

quelques applications que je connais qui utilisent Qt :
Dropbox, OBS, MEGA, VIber, Wireshark, makemkv, yacreader, masterpdfeditor, vapoursynth-editor, SVP, teamspeak3, mkvtoolnix-gui, hplip, scribus WPS-office...

autre DE utilisant Qt5 : http://papyros.io/ et https://lumina-desktop.org/

@ahjolinna Je pense que vous essayez de convaincre la mauvaise foule. Si Chromium ne fait pas le changement, je doute fortement qu'Electron le fasse. Demander à l'équipe Electron de maintenir ce projet ainsi qu'un fork QT5 de Chromium, c'est trop demander.

De plus, ce problème concerne le remplacement de GTK2 par GTK3. Si vous voulez qu'ils envisagent un changement, veuillez créer un nouveau problème. Sinon, c'est hors sujet et remplit ce fil de bruit.

@alzadude, vous devez modifier certains des scripts de génération de grunt afin qu'il ne télécharge pas l'électron préconstruit, modifiez la version package.json pour qu'elle corresponde à la génération d'électrons que vous avez faite localement avec gtk3 et peut-être une modification python ou deux (désolé de partir mémoire en ce moment). Ce n'est pas difficile mais cela me prend toujours une minute lorsque je fais un nouveau build car j'ai toujours l'impression d'oublier les quelques étapes que j'ai prises lors du build précédent.

Si @ tensor5 commence à utiliser gtk3 dans son référentiel arch-atom, je suggérerais peut-être d'essayer cela - sinon je reviendrai ici la prochaine fois que je ferai une construction et documenterai les modifications pour vous (généralement les faire sur le fin de semaine)

@nikolowry merci, certains changements documentés seraient formidables :)

Je suis sur Fedora, donc je chercherais à incorporer les modifications basées sur ce fichier Fedora :

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

Ce Copr semble actuellement être ce qui se rapproche le plus d'un package standard sur Fedora. Il est basé sur ces fichiers de spécifications rpm en amont :

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

Et est mentionné dans ce bogue Bugzilla :

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

Sur la base du travail existant, je chercherais peut-être à créer mon propre Copr, pour les versions gtk3 d'Electron et d'Atom (en forçant les fichiers de spécifications rpm en amont pour incorporer les correctifs nécessaires, en fonction des modifications documentées). À moins que quelqu'un d'autre ne me devance bien sûr :)

J'essaie d'écrire un ebuild gentoo pour cela, mais sans succès. Je serais très reconnaissant si quelqu'un m'aidait à le faire.

@eternal-sorrow Avez-vous déjà jeté un œil à dev-util/electron, l'ebuild qui se trouve actuellement dans l'arborescence officielle de Gentoo ?

@devurandom , je l'ai fait. C'est une très ancienne version d'électron (0.36.12). Je l'ai modifié pour la version actuelle (1.3.1), adapté tous les correctifs, mais j'ai toujours un problème de liaison v8 (beaucoup de symboles v8 non définis).

@eternal-chagrin

1. Contactez [email protected] , le mainteneur de ce paquet.
2. Configurez un dépôt de superposition avec votre ebuild ici sur GH, nous pouvons peut-être le résoudre ensemble.

@eternal-sorrow dans Arch Linux, nous construisons la dernière version d'Electron avec GTK3 , jetez-y un œil.

Des progrès à ce sujet ?

@nikolowry , quelle version d'atome et d'électron utilisez-vous dans votre atom-gtk3 ? J'ai réalisé que les versions actuelles d'atome nécessitent un électron-0,37 et ne peuvent pas fonctionner avec les versions actuelles d'électron. Ai-je tort?

@eternal-sorrow Atom a récemment été mis à jour vers une version plus récente d'Electron.

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

Existe-t-il un moyen d'utiliser gtk3 ? Je l'adorerais surtout pour la meilleure boîte de dialogue de fichier.

Étant donné qu'archlinux a déjà une version gtk3, qu'est-ce qui manque pour avoir ce noyau électronique?

Je pense qu'ils veulent que le changement se fasse en amont. Et c'est officiellement prévu maintenant, voir https://chromium.googlesource.com/chromium/src/+/acc4214c4dece4e70fb53355d557bd45f35965d6/docs/linux_gtk_theme_integration.md#GTK3.

Informations supplémentaires, les canaux de développement chrome/google chrome utilisent gtk 3, ce n'est donc qu'une question de temps maintenant.

Confirmé pour Chrome 59 sur https://bugs.chromium.org/p/chromium/issues/detail?id=79722#c110.

Plus qu'une question de temps maintenant...

Chrome 59 est sorti ! :tada:

Maintenant que Chrome 59 est sorti, ce serait formidable de voir une pré-version d'Electron construite avec GTK3 pour Linux.

Le support de GTK3 est maintenant dans Chromium stable (59), ce qui signifie qu'il sera bientôt supporté dans Electron ! En tant que novice Linux, je ne connais pas vraiment GTK3. En lisant ce fil et en cherchant sur Google, je suppose que cette mise à niveau améliorera l'apparence des menus, des fenêtres, des boîtes de dialogue, etc. Je pense que cela pourrait être une mise à jour digne d'un blog, mais j'aimerais en savoir plus sur la façon dont ce changement affecte les utilisateurs.

J'ai quelques questions:

• Pourquoi voulez-vous le support GTK3 ?
• Je vois la "boîte de dialogue de fichier" mentionnée beaucoup dans ce fil. Qu'est-ce qui n'allait pas dans GTK2 et comment est-il amélioré dans GTK3 ?
• Cette mise à jour améliore-t-elle des choses comme les performances, la compatibilité, etc. ? Ou juste l'interface utilisateur ?
• À quelles autres améliorations les gens peuvent-ils s'attendre ?
• Quelles distributions Linux utilisent GTK(3) ?

@zeke :

Pourquoi voulez-vous le support GTK3 ? Je vois la "boîte de dialogue de fichier" mentionnée beaucoup dans ce fil.

Une amélioration qui m'intéresse est que les applications Electron s'exécutant dans le bac à sable Flatpak utiliseront désormais de manière transparente un portail vers un sélecteur de fichiers sur l'hôte. Cela utiliserait même le bon Qt si l'utilisateur a installé le portail Qt.

Cette mise à jour améliore-t-elle des choses comme les performances, la compatibilité, etc. ? Ou juste l'interface utilisateur ?

En théorie, le support hidpi de Gtk3 pourrait être pertinent, mais je ne sais pas comment cela interagit avec le rendu de Chromium qui contournerait la plupart de cela. Donc, cela ne change probablement que le thème.

Quelles distributions Linux utilisent GTK(3) ?

Effectivement toutes les distributions ont Gtk3. Unity, GNOME, MATE, Cinnamon, Budgie et éventuellement XFCE utilisent Gtk3 comme principale boîte à outils pour les applications.

@zeke

Quelles distributions Linux utilisent GTK(3) ?

Toutes les principales distributions Linux utilisent GTK3 pour leur bureau (shell). Certains ont également une saveur KDE mais la valeur par défaut pour tous est GTK3.

Je vois la "boîte de dialogue de fichier" mentionnée beaucoup dans ce fil. Qu'est-ce qui n'allait pas dans GTK2 et comment est-il amélioré dans GTK3 ?

Oui, bien que les applications GTK2 et GTK3 puissent cohabiter dans le même système, les applications GTK3 sont mieux intégrées aux postes de travail actuels. La boîte de dialogue Sélecteur de fichiers en est un bon exemple.

@zeke

Pourquoi voulez-vous le support GTK3 ?

J'apprécie la cohérence - le dialogue de fichier est assez différent sur GTK 3, les thèmes sont souvent légèrement incohérents entre les versions GTK. J'aime aussi garder mon système minimal, Atom laisser tomber GTK 2 signifiera une raison de moins d'avoir GTK 2 installé.

Je vois la "boîte de dialogue de fichier" mentionnée beaucoup dans ce fil. Qu'est-ce qui n'allait pas dans GTK2 et comment est-il amélioré dans GTK3 ?

Comme ci-dessus, pour moi la chose la plus importante est la cohérence. Le dialogue GTK 3 est en fait considéré comme inférieur par certains, car il utilise une recherche de nom récursive au lieu d'une recherche incrémentielle dans le répertoire.

À quelles autres améliorations les gens peuvent-ils s'attendre ?

Les menus devraient également utiliser GTK, au lieu d'une implémentation personnalisée qui ne semble pas prendre en charge les mnémoniques et sauter entre les menus adjacents à l'aide des touches fléchées.

Atom laissant tomber GTK 2 signifiera une raison de moins d'avoir GTK 2 installé.

Juste pour que je comprenne ce que vous dites ici, @jtojnar : Si vous avez une version plus récente de Linux qui utilise GTK3 par défaut, alors vous devez installer manuellement GTK2 pour prendre en charge les applications qui n'ont pas été mises à jour vers GTK3 ? Outre Atom (et toutes les autres applications Electron), quelles autres applications populaires ont ce problème ?

@zeke L' installation des dépendances est généralement effectuée automatiquement par le gestionnaire de paquets de votre distribution, l'installation de l'application GTK 3 téléchargera également libgtk3 et l'installation de l'application GTK 2 obtiendra libgtk2 . Vous pouvez installer les deux en toute sécurité, c'est juste qu'avec un SSD à faible espace, je veux me débarrasser de tous les packages hérités que je peux.

Pourquoi voulez-vous le support GTK3 ?

GTK3 est plus récent et prend en charge HiDPI.
GTK2 n'est plus développé et n'est pas moderne.

Je vois la "boîte de dialogue de fichier" mentionnée beaucoup dans ce fil. Qu'est-ce qui n'allait pas dans GTK2 et comment est-il amélioré dans GTK3 ?

Je ne sais pas pour celui-ci.

Cette mise à jour améliore-t-elle des choses comme les performances, la compatibilité, etc. ? Ou juste l'interface utilisateur ?

GTK3 est censé mieux utiliser certaines fonctionnalités du processeur et de la RAM, mais je ne suis pas sûr du contraire. Ce serait cependant une grosse mise à jour de l'interface utilisateur.

À quelles autres améliorations les gens peuvent-ils s'attendre ?

Meilleure prise en charge des thèmes.

Quelles distributions Linux utilisent GTK(3) ?

Toutes les distributions ont GTK3 dans leurs référentiels.
De nombreux environnements de bureau majeurs utilisent GTK3, comme Gnome 3, Budgie, Deepin, MATE et bientôt (tm) XFCE également.

Une condition préalable à cela est Chromium 59 pour laquelle il existe une demande d'extraction pour le #9946.

@zeke Le point à

Je vois la "boîte de dialogue de fichier" mentionnée beaucoup dans ce fil. Qu'est-ce qui n'allait pas dans GTK2 et comment est-il amélioré dans GTK3 ?

GTK2 par rapport à GTK3 pourrait être mieux expliqué comme les versions antérieures de Windows ou macOS où l'interface utilisateur avait un aspect visuel différent (différences de mise en page/fonctionnalité de choses comme les navigateurs de fichiers). Si vous exécutez Windows 10 et obtenez une boîte de dialogue de fichier qui ressemble à Windows Vista ou XP, elle semblerait déplacée et pourrait manquer de certaines fonctionnalités/UX.

Sur un environnement de bureau (DE) comme KDE, cela crée toujours une boîte de dialogue GTK3 au lieu de la boîte à outils plus courante pour ce DE, Qt. Il y a donc encore quelques incohérences, mais c'est mieux que GTK2.

Voici quelques exemples sur KDE avec le thème Breeze par défaut :

Dialogue GTK2 avec les applications Electron actuelles - GitKraken :

Dialogue GTK3 - Fusionner :

Boîte de dialogue Qt - Kate :

Boîte de dialogue Mono/.NET(?) - BundleModder - Peu commun sur Linux, les applications Java peuvent également utiliser une boîte à outils peu commune :

Comme vous pouvez le voir, la cohérence du style est assez différente entre les différentes boîtes à outils d'interface utilisateur. Cela peut être déroutant en tant qu'utilisateur occasionnel pourquoi ils sont différents, ce qui vous amène à vous demander s'ils ont le même objectif ou à être frustrés par le fait que les détails de navigation/présentation sont différents entre eux (GTK sur lequel vous pouvez double-cliquer, tandis que Qt peut être configuré pour un seul cliquez sur la navigation dans les dossiers) ou simplement en voyant le manque de cohérence comme non professionnel.

Gnome (DE axé sur GTK) est capable de gérer cela mieux que KDE (DE axé sur Qt) avec une cohérence entre GTK3 et Qt, car la boîte à outils de Qt est conçue pour bien s'intégrer sur toutes les plates-formes, donnant une sensation/expérience native. Les développeurs GTK sont réticents à prendre en charge leur boîte à outils sur des DE autres que Gnome, bien que les développeurs KDE veuillent contribuer au code pour résoudre le problème sur leur DE. Si l'utilisateur n'utilise pas d'anciennes applications utilisant GTK2 ou des kits d'outils peu communs, il aura une meilleure expérience.

Souvent, vous trouverez un mélange d'applications GTK et Qt lorsqu'une boîte à outils n'a pas une offre aussi solide que les autres applications équivalentes de boîtes à outils, pour certains utilisateurs, l'utilisation d'une seule application de boîte à outils est viable (KaOS est une distribution qui s'adresse à Qt5 expérience, avec des applications GTK en option comme Chrome disponibles). Avec la popularité des applications Electron, éviter GTK n'est pas toujours souhaitable.

Pourquoi voulez-vous le support GTK3 ?

Cohérence, la boîte de dialogue de fichier étant celle qui me frappe le plus en tant qu'utilisateur de KDE.

Cette mise à jour améliore-t-elle des choses comme les performances, la compatibilité, etc. ? Ou juste l'interface utilisateur ?
À quelles autres améliorations les gens peuvent-ils s'attendre ?

Bien que je ne connaisse pas grand-chose à FlatPak (applications en bac à sable, distro-agnostiques, un peu comme un Docker/conteneurs pour les applications GUI), je pense que GTK3 a une meilleure histoire que GTK2, y compris l'intégration avec le DE (le thème FlatPak est un autre histoire pour la cohérence, GTK3 dans FlatPak a récemment obtenu un support de thème, d'autres boîtes à outils doivent également l'ajouter). FlatPak, comme mentionné, peut également atténuer les problèmes de dialogue de fichier via la prise en charge des portails.

Personnellement, je ne connais pas grand-chose à propos de GTK2 vs GTK3, mais l'histoire HiDPI sera meilleure pour GTK3 j'imagine (GTK2 pourrait même ne pas l'obtenir?). Je suppose que la prise en charge des thèmes est meilleure, ou du moins, vous aurez plus de chances d'obtenir des thèmes pour GTK3 que pour 2, en particulier à l'avenir. Sur Gnome, la boîte de dialogue de fichier peut être un peu différente avec des décorations côté client (CSD) améliorant l'UX pour ces utilisateurs. Sur KDE, je pense que la prise en charge de GTK3 pourrait mieux fonctionner avec la fonctionnalité de menu global (toujours WIP, macOS comme la barre de menus au lieu d'être liée à la fenêtre des applications).

Quelles distributions Linux utilisent GTK(3) ?

La majorité des distributions modernes utilisent GTK3 ou le prennent en charge pour autant que je sache. GTK2 est assez ancien. Si vous utilisez des applications Chrome ou Electron, vous utilisez GTK (probablement un mélange de 2/3, mais penché davantage vers 3).

@polarathene , vous n'avez pas mentionné que le support GTK3 permet d'ajouter le support Wayland à l'avenir, contrairement à GTK2.

La version JFYI Chromium GTK2 est cassée dans la dernière version stable 60.0.3112.90 et dans la version bêta 61.0.3163.31.
Cela fonctionne dans le dernier master cependant.

Et d'ailleurs, il n'est plus officiellement maintenu.
https://groups.google.com/a/chromium.org/d/msg/chromium-dev/iO3qzex6oYA/Q-i4Cie3BwAJ

Super retour sur les vertus de GTK3, tout le monde. Merci pour votre contribution.

Malheureusement, il semble que la mise à jour GTK3 n'atteindra pas Electron 1.8 avec Chrome 59. Il bloque actuellement la construction, nous devrons donc attendre le prochain Chromium bump à 61 (nous sautons 60) avant que GTK3 ne soit pris en charge dans Electron.

Est-ce exact, @alexeykuzmin ?

@zeke avez-vous une estimation approximative du moment où la bosse du chrome 61 se produira? Nous aimerions planifier notre passage aux composants Web natifs ES6 pour nous aligner sur cette version. Historiquement, les bosses arrivent environ un mois après la sortie ?

@zeke
Oui, nous avons eu quelques soucis avec le GTK3 dans la branche Chromium 59.
Mais nous devrions passer de GTK2 à GTK3 dans la prochaine mise à niveau de Chromium 61.

@cpoole, nous n'avons actuellement pas d'estimation du moment où Chromium 61 atterrira dans Electron, mais cela est en cours d'élaboration sur https://github.com/electron/libchromiumcontent/pull/335. Notre objectif est d'être à terme plus en phase avec les versions de Chromium. Des gens formidables de Microsoft ( @tonyganch , @cifratila , @alexeykuzmin , @alespergl , autres ?) Donc je suis optimiste :)

Pourquoi voulez-vous le support GTK3 ?

@deikatsuo De quel navigateur s'agit-il ? On dirait que Chrome et Epiphany ont eu un bébé...

@mdsitton épiphanie

des nouvelles à ce sujet?

@ziggy42 il devrait déjà être là dans le dernier chrome 61 (https://github.com/electron/electron/pull/10213). Je suppose que ce n'est qu'une question de fusionner dans le master et de faire une version à un moment donné.

J'ai hâte, ces vilains sélecteurs de fichiers me brûlent les yeux :fire:

Ce changement autorisera-t-il CSS dans les applications Electron ?

Donc, le chrome 61 est fusionné, gtk3 doit-il l'accompagner ?

Electron utilise maintenant GTK3 dans la branche master, sera livré dans la prochaine version mineure/majeure.

@ahjolinna

Merci d'avoir consacré un peu de raison à cette discussion.

Vous pourriez être vraiment intéressé par KaOS, qui a déjà été mentionné.
Il est maintenu par la personne même qui a rendu Chakra formidable pendant plusieurs années, à mon humble avis.

@tous

GTK+ 3 est sorti quand ?

Il y a 7 ans.

Laissez cela fondre dans votre bouche pendant un moment.

Et un grand nombre de projets logiciels reposent toujours sur 2.
Puisque le portage est celui d'un plaisir..

XFCE, Mate et un grand nombre d'autres ont mis 6 ans pour porter le code.
D'autres projets sont complètement passés de GTK à Qt en l'espace de 2.

Et oui : GTK+ est développé par GNOME, même le dépôt y est installé.
Il est - par nature et par définition - développé pour GNOME et rien d'autre.

Qt est développé pour une intégration réelle et native dans plusieurs plates-formes.

L'électron c'est quoi ?

Une boutique GNOME ?

Joli.

Pensée intelligente.

C'est la même chose que dans la programmation impérative et fonctionnelle, ainsi que dans tant d'autres aspects ici dans cette scène : les logiciels redondants, anciens et obsolètes sont souvent traités comme une drogue addictive, ce qui en fait un.

Et les nouveaux logiciels intelligents et innovants sont traités par méprise et pure ignorance.

10, 12 projets sont passés de GTK+ à Qt alors que je ne connais pas un seul cas où l'inverse s'est produit.

Laissez cela fondre à nouveau sur votre langue : cela signifie une réécriture complète de l'ensemble de leur code d'interface utilisateur intégré.
Profondément niché, souvent.

Ce qui signifie qu'ils préfèrent cela, par rapport à une mise à niveau majeure de leur outil existant.
Et tous sont satisfaits de cette décision, jusqu'à aujourd'hui.

Leur demander.

Avant de suivre le troupeau sans envisager d'alternatives.

@ahjolinna vous a posté une vidéo de l'une de ces personnes, VLC, Wireshark, LXQt et d'autres projets logiciels remarquables sont également anciennement basés sur GTK.

GTK est juste utilisé dans Chromium comme liaison à Aura et ceci uniquement sous Linux/freeBSD/Solaris et ainsi de suite :
Les versions Windows et macOS en sont exemptes.

:clin d'œil:

Bien que j'obtienne vos points @ShalokShalom , pas besoin d'être impoli, Electron suit ce qui est livré par l'équipe Chromium.

Le bouton de la fourche est en haut d'ailleurs, n'hésitez pas.

Oui, c'était inutilement abrasif.

Mais je suis d'accord. GTK a trop de casse inutile qui cause de la douleur, Qt aurait été un meilleur choix

• SI QtWebEngine fournit un accès suffisant à l'instance de chrome sous-jacente
• SI QtWebEngine suit le plus récent Chromium assez rapidement

Je suggère que nous déplacions la discussion à un endroit plus approprié. @ShalokShalom , que diriez-vous d'ouvrir un nouveau problème ici et de décrire le problème d'une manière plus civile que vous ne l'avez fait tout à l'heure ?

VLC , Wireshark, LXQt et d'autres projets logiciels remarquables sont également anciennement basés sur GTK.

Ce n'est pas vrai. VLC utilisait wxWidgets avant Qt, pas GTK : https://wiki.videolan.org/WxWidgets_Interface/

Il me semble que les gens de GTK ont reconnu depuis un certain temps qu'ils ne communiquaient pas assez bien la casse et le versioning dans la série 3.x et qu'ils essaieront plus fort à l'avenir avec une stabilité à long terme meilleure et plus claire, comme on peut le lire sur https :/ /blog.gtk.org/2016/09/01/versioning-and-long-term-stability-promise-in-gtk/.

Je dirais également que Qt et GTK ne peuvent pas être comparés un à un en raison de leur histoire, de leur soutien et de leurs objectifs différents et, à mon avis, ils ont tous deux des avantages et des inconvénients selon votre point de vue.

Dire que GTK est fait pour et uniquement pour le projet GNOME est aussi, à mon avis, une déclaration globale injuste.

Ha! Je ne connaissais vraiment pas ces plans. on dirait qu'ils ont enfin appris. espérons qu'ils commenceront à considérer tout changement de rupture dans CSS comme un véritable changement de rupture.

la dernière chose que j'ai entendue était le… euh… excentrique GTK 4.0 n'est pas GTK 4 . donc ils arrivent enfin à quelque chose de presque aussi bon que semver ! ils font presque aussi bien que Qt il y a 20 ans ! ??

Nous devrions bientôt voir Electron avec le support natif de GTK3 par défaut sur la base de ce post twitter :

Electron 2.0.0-beta.1 est disponible avec Chromium et Node.js mis à jour, les achats in-app macOS, la prise en charge de GTK3 pour Linux et bien plus encore.

Oui. Le vrai travail pour cela a été fait par les auteurs de Chromium et Electron l'a obtenu grâce à la mise à niveau de Chromium dans Electron 2.0.0.

De plus, le propre code d'Electron a obtenu GTK3ified dans https://github.com/electron/electron/pull/11879

Oui, c'était inutilement abrasif.
Mais je suis d'accord. GTK a trop de casse inutile qui cause de la douleur, Qt
aurait été un meilleur choix
SI QtWebEngine fournit un accès suffisant à l'instance de chrome sous-jacente
SI QtWebEngine suit le plus récent Chromium assez rapidement

Eh bien, c'est le problème principal. Les gens considèrent ce qui est le plus rapide à mettre en œuvre pour eux, ce qui est bien, alors qu'ils oublient très souvent que la mise en œuvre réelle pour le faire fonctionner est quelque chose de très différent de la maintenance à long terme.

Il est clair de mon point de vue que les problèmes mentionnés peuvent être résolus.

Une fois que vous avez comparé le nombre de codeurs qui travaillent réellement sur les ports GTK3 et ceux qui portent l'intégralité de leur code d'interface utilisateur sur une nouvelle boîte à outils, pouvez-vous voir à quel point la différence est incroyable. Je pense avoir déjà posté une vidéo à ce sujet, intitulée 'De GTK à Qt : Un voyage étrange.'

Pourquoi se concentrer sur des logiciels obsolètes, simplement parce qu'ils semblent prêts à l'emploi, au lieu de pirater le support dans Qt ?

C'est ce dogme « J'utilise ce qui semble être prêt », qui ignore complètement les décisions à long terme. Oui, il peut sembler que cela demande un peu plus d'efforts en premier lieu, alors que vous bénéficierez sûrement de la boîte à outils moderne une fois implémentée.

Ce n'est pas non plus si drastique, que QtWebEngine ne suive pas Chrome aussi rapidement :
C'est assez rapide et Qupzilla prouve que vous pouvez faire des choses incroyables avec, en particulier dans un environnement approprié, tel que KaOS.

Pensez-vous vraiment que vous avez besoin de « plus d'accès au Chromium sous-jacent » et que « QtWebEngine ne suit pas Chromium assez rapidement » puisque Qupzilla et d'autres logiciels s'avèrent fournir des logiciels étonnants, maintenus par un seul codeur ?

Vous pensez avoir besoin de plus d'accès et de suivi plus rapide en tant que navigateur Web à part entière dans Electron ? Comment?

Maintenant, vous êtes assis sur cette pile logicielle maladroite dans tellement de projets et de petites équipes parviennent à porter 40 à 60 % de leur code profondément imbriqué vers Qt rapidement et efficacement ;

Quelque chose qu'ils n'ont pas réussi à faire de GTK 2 à GTK 3, ce qui est assez étonnant. Comme dit : La plupart des projets ont pris 6 à 7 ans pour mettre à

Et presque tout le monde semble l'ignorer ? C'est tellement triste, que dans une communauté initialement scientifique, des décisions si primitives continuent de se répandre.

Paix :)

@ShalokShalom , qu'entendez-vous par "logiciel obsolète" ? GTK+ ? Une raison pour laquelle tu dis ça ?

Veuillez arrêter avec ce spam Qt, il s'agit d'un problème concernant le port GTK 3. Si vous ressentez le besoin de convaincre les responsables de passer à Qt, ouvrez une question séparée. Je veux recevoir des nouvelles sur la progression de l'implémentation, pas des messages des fans de Qt.

Verrouillage de cette conversation en raison d'un nombre excessif de discussions hors sujet.

Le verrouillage ne résout qu'un symptôme, mais constitue une solution rapide raisonnable puisque le passage à GTK3 se termine et qu'il ne reste plus grand-chose à discuter sur le sujet de ce problème concernant le passage de GTK2 à GTK3.