Electron: Considere reemplazar GTK2 w GTK3 en compilaciones de Linux

Me parece bien después de la actualización a Chrome 47.

Chrome 47 se lanzó hace tres días. :) http://googlechromereleases.blogspot.se/2015/12/stable-channel-update.html

Profundizó un poco, pero aún no estoy seguro de dónde poner la bandera use_gtk3 ..

@zcbenz o ¿puede darnos sugerencias sobre dónde ponerlo?

No soy un experto en los comportamientos de construcción detrás del sistema de compilación para Chromium, pero leyendo el error relacionado con Chromium allí , debería estar bien que lo agreguemos al variables a common.gypi . La línea relevante está aquí .

En realidad, también estoy probando eso en una caja de Linux. Mi caja de desarrollo actual ejecuta Elementary OS , y cada vez que se ejecuta una aplicación Gtk2, muestra una advertencia Gtk-Message: Failed to load module "pantheon-filechooser-module" ( Ref ). Si las cosas van bien (con suerte), veamos si puedo conseguir un PR también. Sin embargo, definitivamente me encantaría tu información allí.

¿Algún avance en esto? Como usuario de Atom, me gustaría verlo usando GTK3 en lugar de GTK2.

@netsgnut, ¿funciona bien?

¿Qué significa el "%"?

¿Es el único cambio este?

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,

Hay noticias ? ¡El diálogo de archivo abierto GTK2 es bastante complicado de usar!

@ oveja voladora Ah, perdón por el largo silencio de la radio. He estado comprometido con otros proyectos fuera de GitHub, mi culpa.

Volviendo a nuestro caso, eso fue lo que originalmente pensé que debería funcionar, pero misteriosamente falla al construir aplicaciones Gtk3 adecuadas en mi caja. En mi caso, mi intención original es hacer una compilación de Electron que no emita errores en mi caja de desarrollo (que ejecuta Elementary OS Freya). Sin embargo, parece que construir de esa manera no hará que la advertencia desaparezca.

en el # 4642, @zcbenz dijo:

La bandera use_gtk3 solo es significativa en el lado de Chromium, para habilitar GTK3 primero debemos habilitarlo en libchromiumcontent y luego cambiar la configuración del enlace en Electron.

entonces, ¿qué se necesita hacer exactamente?

1. habilitar el uso de GTK3 en libchromiumcontent: se agregó una bandera en chromiumcontent.gypi ser suficiente? ¿Es esto importante o el electrón no usa esa construcción objetivo?
2. cambiar la configuración del enlace en Electron: ¿dónde hacer esto?

No soy un experto en este campo y no estoy seguro de haber entendido mal el comentario de

Respecto a las preguntas:

1. Probablemente no. libchromiumcontent parece, por su apariencia, un montón de scripts que descargan la fuente de cromo desde el origen , parches y reempaquetados para su uso en Atom. Además de cambiar un indicador en chromiumcontent.gypi como ha mencionado, al menos las bibliotecas de dependencia también están empaquetadas correctamente . Vea las instancias de libgtk2ui .
2. Hay fragmentos en Electron que hacen referencia a IU específicas de libgtk2 . Aquellos apuntan a una dependencia dentro del cromo (y / o derivados). Los "enlaces" como en el comentario de @zcbenz probablemente se refieran a ellos.

El error de seguimiento en Chromium refleja algún tipo de estado desde el principio. Uno de los comentaristas nota:

IIRC, requeriría construir una biblioteca libgtk3ui para que coincida con chrome / browser / ui / libgtk2ui /, y tener estas dos bibliotecas cambiadas en el momento del inicio.

Y, al momento de escribir, libgtk3ui aún no existe :( También puede echar un vistazo al código en libgtk2ui.

Estaba entre computadoras portátiles personales después de que publiqué esto originalmente y había estado usando MBP emitido por mi compañía durante unos meses desde entonces. Pero finalmente tengo mi nueva máquina, tiempo de inactividad y decidí intentarlo. Mi progreso hasta ahora:

Pude obtener libchromiumcontent para compilar con gtk3, implicaba lo siguiente:

• agregue 'use_gtk3': 1 en chromiumcontent.gypi.
• sysroot deshabilitado comentando manualmente la llamada de install_sysroot() en el script / actualización. Nota: Dependiendo de la versión de libchromiumcontent, es posible que deba configurar use_sysroot en chromium/src/build/common.gypi en 'use_sysroot': 0 . Supongo que el enfoque correcto en el futuro sería cambiar a debian_jessie para la capacidad de compilación cruzada en las compilaciones.
• ejecutó 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

• corrió script/update -t x64 && script/build -t x64 && script/create-dist -t x64
• esperado por horas :)

Sin embargo, desafortunadamente fui un poco demasiado optimista después de que terminó la construcción, pensando que sería arrastrar y soltar para una construcción de electrones, pero por supuesto que no lo fue. Creo que el siguiente paso es construir una bandeja de brillo local y cualquier otro archivo gyp actualizado para usar las bibliotecas de mi sistema y no sysroot.

Y en lo que respecta a libgtk2ui, tengo problemas para ubicar la referencia de dónde leí esto (tal vez foros de gentoo, rastreador de problemas de cromo o un hilo de la comunidad arch linux), pero creo que Chromium construye libgtk2ui independientemente de gtk3 / gtk2 porque los desarrolladores estaban haciendo lo mínimo para que una compilación con gtk3 funcionara. Podría estar equivocado y no sé cómo esto podría afectar a los parches basados ​​en Electron que se escribieron específicamente para gtk2.

Hago una compilación de chromium-gtk3 semanal para mi navegador personal y libgtk2ui todavía está presente y supongo que está usado.

Volveré aquí con suerte en los próximos días y vincularé a mis repositorios de POC con binarios prediseñados y algunas capturas de pantalla.

¡Listo y espero tener atom-gtk3 en funcionamiento pronto!

El mayor obstáculo fue el uso de debian_wheezy_sysroot en libchromiumcontent / electron / brightray. Los mantenedores de esos repositorios probablemente necesitarán tener algunas discusiones y tomar decisiones si cambiar a jessie o posiblemente hacer que sysroot sea opcional.

Durante el fin de semana intentaré armar un script de nodo o bash para construir un ejecutable distribuible electron gtk3. No creo que se acepte ninguna solicitud de extracción que haga, por lo que, por ahora, esta será probablemente la forma más eficiente para que otros usuarios de gtk3 obtengan y usen la compilación. Y durante las próximas dos semanas, incluso podría intentar poner algunos paquetes AUR para mis compañeros usuarios de Arch.

Estas fueron las advertencias de gtk3 durante la construcción de electrones https://gist.github.com/nikolowry/05865698788d66ae0edfea2eb7c7fb0c

@nikolowry ¿Hay alguna forma de mantener sysroot pero copiar en GTK + 3.x en sysroot?

@paulcbetts Creo que solo si Wheezy se actualiza a Jessie (podría estar equivocado, pero estaría dispuesto a apostar que se encontraría en el infierno de la dependencia si intentara colarse gtk3 allí). Además de gtk3, también necesitamos las siguientes bibliotecas modernas para que gtk3 se compile: wayland-protocols glib-2.0 gdk-3.0 gtk+-unix-print-3.0 .

Suena genial @nikolowry , gracias por tu trabajo. ¿El código fuente está disponible en alguna parte? Me encantaría tener un PPA listo para facilitarnos la vida a los usuarios de Ubuntu.

También me gustaría agregar que este problema no es solo una cuestión de proporcionar widgets modernos. GTK2 no se puede usar en sistemas HiDPI (al menos no con ubuntu 16.04) debido a que todos los íconos en los botones y barras de herramientas son extremadamente pequeños. Afortunadamente, en el caso de Atom, esto parece afectar solo al diálogo de apertura de archivos, al menos hasta donde puedo ver, por lo que Atom sigue siendo bastante utilizable.

@EiNSTeiN Me vincularé en breve a un repositorio de electron-gtk3 para el fin de semana.

Primero, una pequeña historia de fondo: la razón principal por la que estaba decidido a hacer que esto funcionara fue porque uso Atom como mi controlador diario y ya no podía soportar ver el cuadro de diálogo del archivo. Sin embargo, esa compilación tomó más tiempo de lo esperado debido a complicaciones con asar / compiled-cache / npm-not-running-post-install-scripts, pero estoy listo para comenzar ahora.

Había estado reflexionando sobre la mejor manera de hacer esto, por lo que los mantenedores tendrán una buena referencia (sería difícil coordinar las solicitudes de extracción en todos los repositorios individuales) y también para que los posibles usuarios de gtk3 puedan comenzar a funcionar como rápidamente imposible.

Pero no haré compilaciones automatizadas, por lo que todos deberían estar preparados para tiempos de compilación de 4 a 6 horas o para preparar algunos servidores. Podría terminar haciendo un lanzamiento ocasional hasta que estos cambios se reflejen en el repositorio oficial.

Me he centrado en hacer un repositorio con electron como submódulo y escribir un solo script bash para construir electron con todas las bondades de gtk3. Entonces, cada distribución puede tener un punto de partida fácil para eventualmente distribuir paquetes hasta que estos cambios se realicen oficialmente.

Y en la nota hidpi: mi cmd ejecutivo para atom-gtk3 es GTK_THEME=Adwaita:dark GDK_SCALE=2 GDK_DPI_SCALE=.5 /usr/local/share/atom/atom --force-device-scale-factor=1.5 %U . Los indicadores de escala GDK también corrigen el tamaño de la fuente chromium-gtk3 ui. Aquí hay algunas pantallas de atom-gtk3 :

https://goo.gl/ydHspu

Hola,

Pude compilar Electron 1.1.2 con GTK3 en Arch Linux, pasando use_gtk3=1 a libchromiumcontent y cambiando gtk+-2.0 a gtk+-3.0 en brightray.gyp .

Ahora, la aplicación predeterminada de Electron falla cada vez que presiono una tecla.

Detalles aquí: https://github.com/tensor5/arch-atom.

El repositorio de script de compilación:
https://github.com/nikolowry/electron-gtk3

Con suerte, lo habrá terminado para el fin de semana. Es un WIP y aún no crea nada significativo.

@EiNSTeiN y @ tensor5 - https://github.com/nikolowry/electron-gtk3 debería estar construyendo ahora. Tenga en cuenta que solo compila la versión release menos que le indique específicamente que compile tanto debug como release . consulte el archivo README y abra un problema si algo no funciona.

@zcbenz, ¿hay alguna razón histórica para usar Debian Wheezy (sé que a Chromium le gusta ser compatible con LTS)? ¿Quizás agregar una bandera de compilación para usar Jessie / GTK3? Podría trabajar en una solicitud de extracción adecuada si no se opone a la idea, de lo contrario, al menos tiene un script de compilación de referencia sobre lo que se necesita para que GTK3 se compile.

Editar: @ tensor5, ¿estás usando X o Wayland? Sé que las compilaciones de chromium gtk3 se bloquean en eventos de entrada clave en Wayland.

@nikolowry : sí, estaba usando Wayland y, de hecho, funciona bien con X, gracias. ¿Sabes si este problema de Chromium se ha discutido en alguna parte?

Encontré esto: https://bugs.chromium.org/p/chromium/issues/detail?id=615164.

@nikolowry Solo estamos siguiendo las configuraciones de construcción de Chromium, hay muchas distribuciones de Linux y no podemos probarlas todas, mientras que Chromium está completamente probado en todas partes, por lo que es seguro seguir Chromium.

Estoy bien agregando una bandera para compilar para GTK + 3, y agregar un enlace a su script de compilación también me parece bien. Puede ser parte de los temas avanzados de las instrucciones de compilación de Linux .

@zcbenz suena bien: tienen un script de Python que se puede ejecutar que usa Jessie en lugar de Wheezy para sysroot, pero supongo que es mejor esperar a que se establezca como predeterminado en Chromium ascendente.

En general, construir contra la distribución más antigua que puede encontrar es algo bueno cuando se trata de distribuir software debido al control de versiones de glibc ++: la actualización a Jessie podría (aunque lo consideraría mucho más seguro en general) personas huérfanas que tenían Electron trabajando en el pasado. Nos ocupamos mucho de este problema con los usuarios de RHEL

@ tensor5 descubrió cómo lanzar en Wayland. Comenté ese ticket de Chromium y actualicé mi repositorio gtk3.

Solo necesita ejecutar GDK_BACKEND=x11 electron ya que Chromium no se conecta al módulo XWayland automáticamente.

@nikolowry ¡IMPRESIONANTE!

Entonces, si entiendo correctamente, el problema es que GTK3 piensa que electron es una aplicación pura de Wayland, mientras que no lo es.

@ tensor5 exactamente! GTK3 asume que todas las aplicaciones que usan el kit de herramientas están listas para Wayland (por lo tanto, son responsables de cargar XWayland si es necesario).

Me estaba preparando para profundizar en el código fuente de Chromium este fin de semana para resolverlo, y mientras intentaba generar algunos registros, me topé con la solución simple a través de https://fedoraproject.org/wiki/How_to_debug_Wayland_problems.

Chromium y Atom fueron mis últimas aplicaciones que no estaban preparadas para Wayland, ¡¡¡me alegro de que mi computadora portátil Skylake ya no se bloquee a través de xrandr cuando se conecte a varios monitores en modo de dpi mixtos !!

Editar: Sé que también mantiene algunos paquetes AUR, por lo que es posible que desee editar los archivos de escritorio para incluir "env GDK_BACKEND = x11", permitirá que las aplicaciones se ejecuten tanto en X como en Wayland y evitará que todos los demás tengan muchos dolores de cabeza en ¡el futuro!

@nikolowry ¡Ya estoy en eso!

Eventualmente, esto debería arreglarse en la fuente de electrones, usar un script de inicio no es la forma más elegante.

Por cierto, el paquete AUR no es mío. Mantengo un repositorio

@nikolowry Firefox también es una aplicación GTK3 que se basa en Xwayland, pero funciona bien. Así que le eché un vistazo: como puede ver aquí , primero prueba el backend X11 y luego usa el display_name detectado para gdk_display_open .

Probablemente se pueda hacer algo similar en Chromium.

En el sistema operativo elemental, necesitamos GTK3 para usar el selector de archivos pantheon, o obtendremos estos:

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

¿Por qué no simplemente admitir / portar a Qt5-WebEngine ? usa el motor de chromium de todos modos, y en Qt todo parece mucho más nativo a diferencia de en gtk ...

además, qt5 no está roto todo el tiempo como gtk3 que cambia sus F ** king API cada vez solo porque no les importa nada más que el desarrollo de gnome.

aquí hay una gran presentación de video por qué gtk es malo y qt es mejor (2 años pero aún bueno y relevante)

Qt 5.6.x ahora está en LTS y su licencia cambió a 5.7 , eso es mucho mejor para los usuarios / desarrolladores de código abierto

Personalmente, no entiendo por qué la gente usa gtk fuera de gnome, cuando no está diseñado para eso.

@ahjolinna En realidad, GTK + también está destinado a ser utilizado para el desarrollo de aplicaciones fuera de las cosas de Gnome. De cualquier manera, cambiar las API a QT sería una pesadilla para el equipo de Electron, ya que requeriría una gran cantidad de parches desde Chromium upstream. No vale la pena.

GTK + 3 _está_ intrínsecamente casado con GNOME, ya que básicamente (?) Todos los desarrolladores de GTK son desarrolladores de GNOME, empleados por Red Hat.

la mencionada rotura de la API de GTK ocurre porque Red Hat prioriza el avance de GNOME. @ahjolinna tiene razón en que Qt5 es más estable, _pero_ solo proporciona acceso limitado a la instancia de cromo.

la razón también es la estabilidad: el cromo en sí se rompe lo suficiente como para que solo puedan comprometer sus recursos para mantener su API estable en algunas áreas.

@nikolowry si https://github.com/nikolowry/electron-gtk3 para construir electrones con soporte gtk3, ¿qué necesitaría cambiar en la construcción del átomo para construir un atom-gtk3?

Para aquellos que usan una compilación gtk3, probablemente vean texto en blanco en la barra de menú cuando usan un tema claro. Este parche resuelve el problema.

Voy a corregir las otras advertencias de compilación de gtk3 en los próximos días.

El menú en Chromium con Gtk2 no es 'estilo gtk nativo' y es muy feo. ¿La compilación Gtk3 solucionará esto?

@Menci. No, la barra de menú con gtk3 se ve exactamente igual que con gtk2. Tienes razón, no es completamente nativo, simplemente los colores del texto y el fondo siguen el tema gtk.
Miré el código en los últimos días para ver si podía solucionarse. Un problema es que el código gtk nativo está oculto detrás de capas de envoltorios multiplataforma. Tal vez los expertos en gtk puedan ayudar con esto.

@ tensor5 Creo que el menú debería implementarse en los contenedores multiplataforma. Al igual que el menú de OS X es nativo y el código nativo de Cocoa también está oculto detrás de capas de envoltorios multiplataforma.

@Menci Por supuesto, es la única forma en que se podría aceptar dicho parche.

También sería bueno tener un menú de la aplicación Gnome.

Puede ver cómo lo hizo LibreOffice, es de una manera similar.

Creo que los menús de LibreOffice no son realmente nativos. No tienen la sombra paralela y muestran / ocultan animaciones.

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

Las aplicaciones GTK + nunca se han visto nativas fuera de gnome (y otras derivaciones de gtk), siempre se han visto horribles en KDE, LXQt) y Unity 8 tendrá el mismo problema cuando llegue (está basado en Qt5). El equipo de KDE ha intentado trabajar con el equipo de gtk con este problema, pero han sido 100% idiotas y no les importa que su API cambie / se rompa con cada maldita actualización y eso romperá (algunas) cosas de KDE como el tema breeze-gtk , que por cierto. tenía que estar codificado debido al estúpido razonamiento de los equipos gtk. *

por cierto. con KDE, LXQt y Unity 8 + Ubuntu Touch y SailfishOS, la "cuota de mercado" de Qt5 se ha vuelto mucho más grande que gtk y eso tendrá un gran efecto al menos a largo plazo

PD. sobre libreoffice, puedes construirlo sin GTK y tenerlo usando el selector de archivos nativo, esto es lo que hace, por ejemplo, ChakraOS, PKGBUILD , ¿por qué? porque su distribución centrada en KDE / Qt a la que le gusta evitar el uso de GTK tanto como sea posible

editado

* Los desarrolladores de GTK bloquearon el acceso a los motores de temas, que se usaban anteriormente para la integración de GTK en KDE, por lo que ahora la única forma es probar el "método CSS".

algunas aplicaciones que conozco que usan Qt:
Dropbox, OBS, MEGA, VIber, Wireshark, makemkv, yacreader, masterpdfeditor, vapoursynth-editor, SVP, teamspeak3, mkvtoolnix-gui, hplip, scribus WPS-office ...

otro DE usando Qt5: http://papyros.io/ y https://lumina-desktop.org/

@ahjolinna Creo que estás tratando de convencer a la gente equivocada. Si Chromium no está haciendo el cambio, dudo mucho que Electron lo haga. Pedirle al equipo de Electron que mantenga este proyecto así como una bifurcación QT5 de Chromium es pedir demasiado.

Además, este problema se trata de reemplazar GTK2 con GTK3. Si desea que consideren un cambio, haga un nuevo número. De lo contrario, está fuera de tema y llena este hilo de ruido.

@alzadude tienes que editar algunos de los scripts de compilación de grunt para que no descargue el electrón precompilado, edita la versión package.json para que coincida con la compilación de electrones que hiciste localmente con gtk3 y tal vez una edición de Python o dos memoria ahora mismo). No es difícil, pero siempre me toma un minuto cuando hago una nueva construcción porque parece que siempre olvido los pocos pasos que di en la última construcción anterior.

Si @ tensor5 está comenzando a usar gtk3 en su repositorio arch-atom, sugeriría que lo intente; de ​​lo contrario, volveré a aparecer aquí la próxima vez que haga una compilación y documente los cambios por usted (por lo general, hágalos en el fin de semana)

@nikolowry gracias, algunos cambios documentados serían geniales :)

Estoy en Fedora, así que estaría buscando incorporar los cambios basados ​​en esta copia de seguridad de Fedora:

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

Este Copr parece ser actualmente lo más parecido a un paquete estándar en Fedora. Se basa en estos archivos de especificaciones de rpm ascendentes:

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

Y se menciona en este error de Bugzilla:

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

Basado en el trabajo existente, posiblemente buscaría hacer mi propio Copr, para compilaciones gtk3 de Electron y Atom (bifurcando los archivos de especificaciones de rpm ascendentes para incorporar los parches necesarios, basados ​​en los cambios documentados). A menos que alguien más me gane, por supuesto :)

Estoy tratando de escribir un ebuild gentoo para esto, pero sin éxito. Estaría muy agradecido si alguien me ayudara a hacer esto.

@ eternal-sorrow ¿Ya echó un vistazo a dev-util / electron, el ebuild que se encuentra actualmente en el árbol oficial de Gentoo?

@devurandom , lo hice. Es una versión muy antigua de electron (0.36.12). Lo modifiqué para la versión actual (1.3.1), adapté todos los parches, pero aún tengo un problema de vinculación v8 (muchos símbolos v8 indefinidos).

@Dolor eterno

1. Ponte en contacto con [email protected] , el mantenedor de ese paquete.
2. Configure un repositorio de superposición con su ebuild aquí en GH, tal vez podamos resolverlo juntos.

@ eternal-sorrow en Arch Linux creamos la última versión de Electron con GTK3 ,

¿Algún progreso en esto?

@nikolowry , ¿qué versión de átomo y electrón estás usando en tu atom-gtk3? Me di cuenta de que las versiones actuales del átomo requieren un electrón-0.37 y no pueden funcionar con las versiones actuales del electrón. ¿Me equivoco?

@ eternal-sorrow Atom se actualizó recientemente a una versión más reciente de Electron.

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

¿Hay alguna forma de usar gtk3? Me encantaría especialmente por el mejor diálogo de archivo.

Dado que archlinux ya tiene una compilación gtk3, ¿qué falta para tener este núcleo de electrones?

Creo que quieren que el cambio ocurra aguas arriba. Y ahora está oficialmente planeado, consulte https://chromium.googlesource.com/chromium/src/+/acc4214c4dece4e70fb53355d557bd45f35965d6/docs/linux_gtk_theme_integration.md#GTK3.

Información adicional, los canales de desarrollo de chrome / google chrome están usando gtk 3, por lo que ahora es solo cuestión de tiempo.

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

Solo es cuestión de tiempo ahora ...

¡Chrome 59 ya está disponible! : tada:

Ahora que Chrome 59 está disponible, sería genial ver una versión preliminar de Electron construida con GTK3 para Linux.

El soporte GTK3 ahora está en Chromium estable (59), lo que significa que pronto será compatible con Electron . Como novato en Linux, no estoy realmente familiarizado con GTK3. Al leer este hilo y buscar en Google, deduzco que esta actualización mejorará la apariencia de menús, ventanas, diálogos, etc. Creo que esta podría ser una actualización digna de un blog, pero me encantaría saber más sobre cómo este cambio afecta a los usuarios.

Tengo algunas preguntas:

• ¿Por qué quieres la compatibilidad con GTK3?
• Veo que el "diálogo de archivo" se menciona mucho en este hilo. ¿Qué tenía de malo en GTK2 y cómo se mejora en GTK3?
• ¿Esta actualización mejora aspectos como el rendimiento, la compatibilidad, etc.? ¿O simplemente UI?
• ¿Qué otras mejoras podría esperar la gente?
• ¿Qué distribuciones de Linux usan GTK (3)?

@zeke :

¿Por qué quieres la compatibilidad con GTK3? Veo que el "diálogo de archivo" se menciona mucho en este hilo.

Una mejora que me interesa es que las aplicaciones que se ejecutan en el interior del Electrón Flatpak recinto de seguridad usarán ahora sin problemas un portal a un selector de archivos en el host. Esto incluso usaría el Qt correcto si el usuario tiene instalado el portal Qt.

¿Esta actualización mejora aspectos como el rendimiento, la compatibilidad, etc.? ¿O simplemente UI?

En teoría, el soporte hidpi de Gtk3 podría ser relevante, pero no sé cómo interactúa esto con el renderizado de Chromium, lo que evitaría la mayor parte de eso. Así que probablemente solo cambie la tematización.

¿Qué distribuciones de Linux usan GTK (3)?

Efectivamente, todas las distribuciones tienen Gtk3. Unity, GNOME, MATE, Cinnamon, Budgie y, finalmente, XFCE utilizan Gtk3 como su kit de herramientas principal para las aplicaciones.

@zeke

¿Qué distribuciones de Linux usan GTK (3)?

Todas las principales distribuciones de Linux utilizan GTK3 para su escritorio (shell). Algunos también tienen un sabor KDE, pero el predeterminado para todos es GTK3.

Veo que el "diálogo de archivo" se menciona mucho en este hilo. ¿Qué tenía de malo en GTK2 y cómo se mejora en GTK3?

Sí, aunque las aplicaciones GTK2 y GTK3 pueden vivir juntas en el mismo sistema, las aplicaciones GTK3 están mejor integradas con los escritorios actuales. El cuadro de diálogo Selector de archivos es un buen ejemplo.

@zeke

¿Por qué quieres la compatibilidad con GTK3?

Valoro la coherencia: el diálogo del archivo es bastante diferente en GTK 3, los temas a menudo son ligeramente inconsistentes entre las versiones de GTK. También me gusta mantener mi sistema al mínimo, Atom eliminar GTK 2 significará una razón menos para tener GTK 2 instalado.

Veo que el "diálogo de archivo" se menciona mucho en este hilo. ¿Qué tenía de malo en GTK2 y cómo se mejora en GTK3?

Como antes, para mí lo más importante es la coherencia. El diálogo GTK 3 en realidad es considerado inferior por algunos, ya que usa búsqueda de nombre recursiva en lugar de búsqueda incremental en el directorio.

¿Qué otras mejoras podría esperar la gente?

Los menús también deberían usar GTK, en lugar de una implementación personalizada que no parece admitir mnemónicos y saltar entre menús adyacentes usando las teclas de flecha.

La caída de átomo GTK 2 significará una razón menos para tener GTK 2 instalado.

Solo para que entiendo lo que estás diciendo aquí, @jtojnar : si tienes una versión más nueva de Linux que usa GTK3 de forma predeterminada, ¿tienes que instalar manualmente GTK2 para admitir aplicaciones que no se hayan actualizado a GTK3? Además de Atom (y todas las demás aplicaciones de Electron), ¿qué otras aplicaciones populares tienen este problema?

@zeke La instalación de dependencias generalmente se realiza automáticamente por el administrador de paquetes de su distribución, la instalación de la aplicación GTK 3 también descargará libgtk3 y la instalación de la aplicación GTK 2 obtendrá libgtk2 . Puede tener ambos instalados de forma segura, es solo que con un SSD con poco espacio, quiero deshacerme de todos los paquetes heredados que pueda.

¿Por qué quieres la compatibilidad con GTK3?

GTK3 es más nuevo y tiene soporte HiDPI.
GTK2 ya no está desarrollado y no es moderno.

Veo que el "diálogo de archivo" se menciona mucho en este hilo. ¿Qué tenía de malo en GTK2 y cómo se mejora en GTK3?

No sé sobre este.

¿Esta actualización mejora aspectos como el rendimiento, la compatibilidad, etc.? ¿O simplemente UI?

Se dice que GTK3 utiliza mejor algunas funciones de CPU y RAM, pero no estoy seguro de lo contrario. Sin embargo, sería una gran actualización de la interfaz de usuario.

¿Qué otras mejoras podría esperar la gente?

Mejor soporte de temas.

¿Qué distribuciones de Linux usan GTK (3)?

Todas las distribuciones tienen GTK3 en sus repositorios.
Muchos entornos de escritorio importantes utilizan GTK3, como Gnome 3, Budgie, Deepin, MATE y pronto (tm) XFCE también.

Un requisito previo para esto es Chromium 59, que existe una solicitud de extracción para # 9946.

La conclusión principal de

Veo que el "diálogo de archivo" se menciona mucho en este hilo. ¿Qué tenía de malo en GTK2 y cómo se mejora en GTK3?

GTK2 en comparación con GTK3 podría explicarse mejor como versiones anteriores de Windows o macOS, donde la interfaz de usuario tenía un aspecto visual diferente (diferencias de diseño / funcionalidad de cosas como los navegadores de archivos). Si ejecuta Windows 10 y obtiene un cuadro de diálogo de archivo que se parece a Windows Vista o XP, se vería fuera de lugar y posiblemente carecería de ciertas características / UX.

En un entorno de escritorio (DE) como KDE, esto aún crea un cuadro de diálogo GTK3 en lugar del conjunto de herramientas más común para ese DE, Qt. Así que todavía hay algo de inconsistencia, pero es mejor que GTK2.

Aquí hay algunos ejemplos en KDE con el tema Breeze predeterminado:

Diálogo GTK2 con aplicaciones actuales de Electron - GitKraken:

Cuadro de diálogo GTK3 - Meld:

Diálogo Qt - Kate:

Diálogo Mono / .NET (?) - BundleModder - Poco común en Linux, las aplicaciones Java también pueden usar un conjunto de herramientas poco común:

Como puede ver, la coherencia del estilo es bastante diferente en los diferentes kits de herramientas de la interfaz de usuario. Eso puede ser confuso como usuario casual por qué son diferentes, lo que lo lleva a preguntarse si tienen el mismo propósito o si se siente frustrado con los detalles de navegación / presentación que son diferentes en ellos (GTK puede hacer doble clic en, mientras que Qt puede estar configurado para un solo haga clic en navegación de carpetas) o simplemente ver la falta de coherencia como poco profesional.

Gnome (DE enfocado en GTK) es capaz de manejar esto mejor que KDE (DE enfocado en Qt) con consistencia entre GTK3 y Qt, ya que el kit de herramientas de Qt está diseñado para integrarse bien entre plataformas dando una sensación / experiencia nativa. Los desarrolladores de GTK son reacios a admitir su kit de herramientas en DE que no sean Gnome, a pesar de que los desarrolladores de KDE quieren contribuir con código para abordar el problema en su DE. Si el usuario no está usando aplicaciones más antiguas que usan GTK2 o kits de herramientas poco comunes, tendrá una experiencia más agradable.

A menudo, encontrará una combinación de aplicaciones GTK y Qt cuando un kit de herramientas no tiene una oferta tan sólida como la aplicación equivalente de otros kits de herramientas, para algunos usuarios solo es viable usar una sola aplicación de kits de herramientas (KaOS es una distribución que se adapta a Qt5 experiencia, con aplicaciones GTK opcionales como Chrome disponibles). Con la popularidad de las aplicaciones de Electron, evitar GTK no siempre es deseable.

¿Por qué quieres la compatibilidad con GTK3?

Consistencia, el diálogo de archivo es uno de los que más me llama la atención como usuario de KDE.

¿Esta actualización mejora aspectos como el rendimiento, la compatibilidad, etc.? ¿O simplemente UI?
¿Qué otras mejoras podría esperar la gente?

Si bien no sé mucho sobre FlatPak (aplicaciones de espacio aislado, agnósticas de distribución, algo así como un Docker / contenedores para aplicaciones GUI), creo que GTK3 tiene una mejor historia allí que GTK2, incluida la integración con DE (la tematización de FlatPak es otra historia para la coherencia, GTK3 en FlatPak recientemente obtuvo soporte para temas, otros kits de herramientas deben agregar esto también). FlatPak como se mencionó también puede aliviar los problemas de diálogo de archivos a través de su soporte de portales.

No sé mucho sobre GTK2 vs GTK3 personalmente, pero la historia de HiDPI será mejor para GTK3, imagino (¿GTK2 podría ni siquiera conseguirlo?). Supongo que la compatibilidad con temas es mejor, o al menos es más probable que obtengas temas para GTK3 que para 2, especialmente en el futuro. En Gnome, el cuadro de diálogo del archivo puede ser un poco diferente con las decoraciones del lado del cliente (CSD) que mejoran la UX para esos usuarios. En KDE, creo que la compatibilidad con GTK3 podría funcionar mejor con la función de menú global (todavía WIP, macOS como barra de menú en lugar de estar vinculado a la ventana de aplicaciones).

¿Qué distribuciones de Linux usan GTK (3)?

La mayoría de las distribuciones modernas usan GTK3 o lo admiten, hasta donde yo sé. GTK2 es bastante antiguo. Si está usando aplicaciones de Chrome o Electron, está usando GTK (probablemente una combinación de 2/3, pero inclinándose más hacia 3).

@polarathene , no mencionaste que la compatibilidad con GTK3 permite agregar compatibilidad con Wayland en el futuro, mientras que GTK2 no.

La compilación JFYI Chromium GTK2 está rota en la última versión estable 60.0.3112.90 y en la versión beta 61.0.3163.31.
Sin embargo, funciona en el último maestro.

Y por cierto, ya no se mantiene oficialmente.
https://groups.google.com/a/chromium.org/d/msg/chromium-dev/iO3qzex6oYA/Q-i4Cie3BwAJ

Comentarios impresionantes sobre las virtudes de GTK3, todos. Gracias por tu contribución.

Desafortunadamente, parece que la actualización de GTK3 no aterrizará en Electron 1.8 con Chrome 59. Actualmente está bloqueando la compilación, por lo que tendremos que esperar hasta el próximo aumento de Chromium a 61 (nos saltamos 60) antes de que se admita GTK3 en Electron.

¿Es eso correcto, @alexeykuzmin?

@zeke , ¿tiene alguna estimación aproximada de cuándo ocurrirá la protuberancia del cromo 61? Nos gustaría planificar nuestro cambio a los componentes web nativos de ES6 para alinearnos con esa versión. Históricamente, los golpes se producen aproximadamente un mes después del lanzamiento.

@zeke
Sí, tuvimos algunos problemas con el GTK3 en la rama Chromium 59.
Pero deberíamos hacer un cambio de GTK2 a GTK3 en la próxima actualización de Chromium 61.

@cpoole , actualmente no tenemos una estimación de cuándo aterrizará Chromium 61 en Electron, pero ahora se está trabajando en https://github.com/electron/libchromiumcontent/pull/335. Nuestro objetivo es eventualmente estar más en sintonía con las versiones de Chromium. Algunas personas increíbles de Microsoft ( @tonyganch , @cifratila , @alexeykuzmin , @alespergl , ¿otros?) Han estado ayudando en ese proceso, que está liberando al equipo de Electron de GitHub para que se concentre en mejorar la IC y suavizar el proceso de liberación de Electron. Entonces soy optimista :)

¿Por qué quieres la compatibilidad con GTK3?

@deikatsuo ¿Qué navegador es ese? Parece que Chrome y Epifanía tuvieron un bebé ...

@mdsitton epifanía 👍

¿Alguna noticia sobre esto?

@ ziggy42 ya debería estar allí en la última

No puedo esperar, esos feos recolectores de archivos me queman los ojos: fuego:

¿Este cambio permitirá CSS en aplicaciones de Electron?

Entonces, el cromo 61 se fusiona, ¿vendrá gtk3 con él?

Electron ahora está usando GTK3 en la rama maestra, se enviará en la próxima versión menor / mayor.

@ahjolinna

Gracias por gastar un poco de cordura en esta discusión.

Es posible que esté realmente interesado en KaOS, que ya se mencionó.
Lo mantiene la misma persona que hizo que Chakra fuera genial durante varios años, en mi humilde opinión.

@todos

GTK + 3 se lanzó cuando?

hace 7 años.

Deja que eso se derrita en tu boca por un tiempo.

Y todavía hay una gran cantidad de proyectos de software en 2.
Ya que portar es un placer.

XFCE, Mate y muchos otros tardaron 6 años en portar el código.
Otros proyectos cambiaron completamente de GTK a Qt en 2.

Y sí: GTK + está desarrollado por GNOME, incluso el repositorio está allí.
Está, por naturaleza y definición, desarrollado para GNOME y nada más.

Qt está desarrollado para una integración verdadera y nativa en varias plataformas.

¿Electrón es qué?

¿Una tienda GNOME?

Buena esa.

Pensamiento inteligente.

Es lo mismo que en la programación imperativa y funcional, así como en muchos otros aspectos aquí en esta escena: El software redundante, viejo y desactualizado a menudo se trata como una droga adictiva, lo que lo convierte en uno.

Y el software nuevo, inteligente e innovador es tratado por conceptos erróneos y por pura ignorancia.

10, 12 proyectos cambiaron de GTK + a Qt mientras que no conozco un solo caso, donde sucedió al revés.

Deje que esto se derrita en su lengua nuevamente: eso significa una reescritura completa de todo su código de interfaz de usuario integrado.
Profundamente anidado, a menudo.

Lo que significa que lo prefieren, en comparación con una actualización importante de su herramienta existente.
Y todos están contentos con esa decisión, hasta el día de hoy.

Pregúntales.

Antes de seguir la manada sin considerar alternativas.

@ahjolinna te publicó un video de una de estas personas, VLC, Wireshark, LXQt y otros proyectos de software notables también se basaron anteriormente en GTK.

GTK solo se usa en Chromium como un enlace a Aura y esto solo en Linux / freeBSD / Solaris y así sucesivamente:
Las compilaciones de Windows y macOS están libres de él.

:guiño:

Aunque obtengo tus puntos @ShalokShalom , no hay necesidad de ser grosero, Electron sigue lo que entrega el equipo de Chromium.

El botón de la bifurcación está en la parte superior por cierto, siéntete libre.

Sí, esto fue innecesariamente abrasivo.

Pero estoy de acuerdo. GTK tiene demasiadas roturas innecesarias que causan dolor, Qt habría sido una mejor opción

• SI QtWebEngine proporciona suficiente acceso a la instancia de cromo subyacente
• SI QtWebEngine rastrea el Chromium más nuevo con la suficiente rapidez

Sugiero que llevemos la discusión a un lugar más apropiado. @ShalokShalom , ¿qué tal si abre un nuevo número aquí y describe el problema de una manera más civilizada de lo que lo hizo hace un momento?

VLC , Wireshark, LXQt y otros proyectos de software notables también se basaron anteriormente en GTK.

Eso no es cierto. VLC estaba usando wxWidgets antes de Qt, no GTK: https://wiki.videolan.org/WxWidgets_Interface/

Me parece que la gente de GTK ha reconocido desde hace bastante tiempo que no comunicaron la rotura y el control de versiones lo suficientemente bien en la serie 3.xy se esforzarán más en el futuro con una estabilidad mejor y más clara a largo plazo, como se puede leer en https: / /blog.gtk.org/2016/09/01/versioning-and-long-term-stability-promise-in-gtk/.

También diría que Qt y GTK no se pueden comparar uno a uno debido a la historia, el respaldo y los objetivos diferentes y, en mi opinión, ambos tienen pros y contras según su punto de vista.

Afirmar que GTK está hecho para y solo para el proyecto GNOME también es, en mi opinión, una declaración general injusta.

¡decir ah! Realmente no sabía acerca de esos planes. parece que por fin han aprendido. esperemos que comiencen a considerar cualquier cambio radical en CSS como un cambio radical real.

lo último que escuché fue el… umm… excéntrico GTK 4.0 no es GTK 4 . ¡así que finalmente están llegando a algo casi tan bueno como semver! ¡Lo hacen casi tan bien como lo hizo Qt hace 20 años! 😁

Deberíamos ver a Electron con soporte nativo GTK3 por defecto pronto según esta publicación de Twitter :

Electron 2.0.0-beta.1 está disponible con Chromium y Node.js actualizados, compras integradas en macOS,

Si. El trabajo real para esto fue realizado por los autores de Chromium y Electron lo consiguió a través de la actualización de Chromium en Electron 2.0.0.

Además, el propio código de Electron obtuvo GTK3ified en https://github.com/electron/electron/pull/11879

Sí, esto fue innecesariamente abrasivo.
Pero estoy de acuerdo. GTK tiene demasiadas roturas innecesarias que causan dolor, Qt
hubiera sido una mejor elección
SI QtWebEngine proporciona suficiente acceso a la instancia de cromo subyacente
SI QtWebEngine rastrea el Chromium más nuevo con la suficiente rapidez

Bueno, este es el problema principal. La gente considera qué es lo más rápido de implementar para ellos, lo cual está bien, mientras que a menudo olvidan que la implementación real para que funcione es algo muy diferente del mantenimiento a largo plazo.

Desde mi punto de vista, está muy claro que los problemas mencionados pueden abordarse.

Una vez que compare la cantidad de codificadores que realmente trabajan en los puertos GTK3 y los que transfieren todo su código de interfaz de usuario a un nuevo conjunto de herramientas, puede ver cuán asombrosa es la diferencia. Creo que ya publiqué un video al respecto, llamado 'De GTK a Qt: Un viaje extraño'.

¿Por qué centrarse en software obsoleto, simplemente porque parece listo para usar, en lugar de piratear el soporte en Qt?

Es que 'uso lo que parece estar listo' dogma, que ignora por completo las decisiones a largo plazo. Sí, puede parecer que requiere un poco más de esfuerzo en primer lugar, mientras que ustedes seguramente se beneficiarán del conjunto de herramientas moderno una vez implementado.

Tampoco es tan drástico, que QtWebEngine no siga a Chrome tan rápido:
Es lo suficientemente rápido y Qupzilla demuestra que puedes hacer cosas increíbles con él, especialmente en un entorno adecuado, como KaOS.

¿De verdad crees que necesitas 'más acceso al Chromium subyacente' y que 'QtWebEngine no sigue a Chromium lo suficientemente rápido' ya que Qupzilla y otro software han demostrado ofrecer un software increíble, mantenido por un solo codificador?

¿Cree que necesita más acceso y seguimiento más rápido como un navegador web completo en Electron? ¿Cómo es eso?

Ahora, usted se sienta en esta torpe pila de software en tantos proyectos y los equipos pequeños logran trasladar el 40-60% de su código profundamente anidado a Qt de manera rápida y eficiente;

Algo que no lograron hacer desde GTK 2 hasta GTK 3, que es bastante sorprendente. Como se dijo: la mayoría de los proyectos tardaron entre 6 y 7 años en actualizar una versión principal

¿Y casi todo el mundo parece ignorar eso? Es tan triste, que en una comunidad inicialmente científica, las decisiones tan primitivas continúen extendiéndose.

Paz :)

@ShalokShalom , ¿qué quieres decir con "software obsoleto"? GTK +? ¿Alguna razón por la que dices eso?

Deténgase con este spam Qt, este es un problema sobre el puerto GTK 3. Si siente la necesidad de convencer a los encargados de mantenimiento de que se cambien a Qt, abra un problema por separado. Quiero recibir noticias sobre el progreso de la implementación, no mensajes de fanboys de Qt.

Bloquear esta conversación debido a una excesiva discusión fuera del tema.

El bloqueo solo aborda un síntoma, pero es una solución rápida razonable, ya que el cambio a GTK3 está terminando y no queda mucho por discutir sobre el tema de este problema de pasar de GTK2 a GTK3.