Electron: Ziehen Sie in Erwägung, GTK2 durch GTK3 in Linux-Builds zu ersetzen

Klingt gut für mich, nachdem wir auf Chrome 47 aktualisiert haben.

Chrome 47 wurde vor drei Tagen veröffentlicht. :) http://googlechromereleases.blogspot.se/2015/12/stable-channel-update.html

Habe mich ein bisschen damit beschäftigt, bin mir aber immer noch nicht sicher, wo ich das use_gtk3-Flag setzen soll.

@zcbenz oder können Sie uns ablegen sollen ?

Ich bin kein Experte für das Bauverhalten hinter dem Build-System für Chromium, aber wenn ich den Chromium-bezogenen Fehler dort lese , sollte es in Ordnung sein, dass wir ihn zu variables bis common.gypi hinzufügen. Die entsprechende Zeile ist hier .

Eigentlich teste ich das auch auf einer Linux-Box. Auf meiner aktuellen Entwicklungsbox läuft Elementary OS , und wenn eine Gtk2-Anwendung ausgeführt wird, wird eine Warnung angezeigt Gtk-Message: Failed to load module "pantheon-filechooser-module" ( Ref ). Wenn es (hoffentlich) glatt läuft, schauen wir mal, ob ich auch eine PR bekomme. Würde auf jeden Fall Ihre Eingaben dort lieben.

Gibt es hierzu Neuigkeiten? Als Atom-Benutzer würde ich es gerne sehen, wenn GTK3 anstelle von GTK2 verwendet wird.

@netsgnut funktioniert es gut?

Was bedeuten die „%“?

ist die einzige Änderung diese?

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,

Irgendwelche Neuigkeiten ? Der Dialog zum Öffnen von GTK2-Dateien ist ziemlich mühsam!

@flying-sheep Ah, sorry für die lange Funkstille. Engagiert für andere Projekte außerhalb von GitHub, mein Fehler.

Zurück zu unserem Fall, das war das, was ich ursprünglich dachte, sollte funktionieren, aber es gelingt auf mysteriöse Weise nicht, richtige Gtk3-Anwendungen auf meiner Box zu erstellen. In meinem Fall ist es meine ursprüngliche Absicht, einen Electron-Build zu erstellen, der unter meiner Entwicklungsbox (auf der Elementary OS Freya ausgeführt wird) keine Fehler ausgibt. Es scheint jedoch, dass das Bauen auf diese Weise die Warnung nicht wirklich verschwinden lässt.

in #4642 sagte @zcbenz :

Das Flag use_gtk3 ist nur auf Seiten von Chromium von Bedeutung. Um GTK3 zu aktivieren, müssen wir es zuerst in libchromiumcontent aktivieren und dann die Linkeinstellungen in Electron ändern.

was ist also genau zu tun?

1. mit GTK3 in libchromiumcontent aktiviert: wird das Hinzufügen einer Flagge in chromiumcontent.gypi ausreichend sein? Ist dies von Bedeutung oder verwendet das Elektron diesen Target-Build nicht?
2. Ändern Sie die Link-Einstellungen in Electron: Wo geht das?

Ich bin kein Experte auf diesem Gebiet und nicht sicher, ob ich den Kommentar von @zcbenz falsch verstanden habe ; nur meine 2 Cent.

Zu den Fragen:

1. Wahrscheinlich nicht. libchromiumcontent scheint, wie es aussieht, eine Reihe von Skripten zu sein, die Chromium-Quellen von Upstream- , Patches und Neupaketen für die Verwendung in Atom herunterladen . Abgesehen von der Änderung eines Flags auf chromiumcontent.gypi, wie Sie bereits erwähnt haben, werden zumindest auch Abhängigkeitsbibliotheken richtig gepackt . Sehen Sie sich die Instanzen von libgtk2ui .
2. Es gibt Fragmente in Electron, die auf libgtk2-spezifische UIs verweisen . Diese weisen auf eine Abhängigkeit innerhalb von Chrom (und/oder Derivaten) hin. "Links" wie im Kommentar von @zcbenz beziehen sich wahrscheinlich auf diese.

Der Tracking-Bug auf Chromium spiegelt eine Art Status vom Upstream wider. Einer der Kommentatoren bemerkt:

IIRC, es würde erfordern, eine libgtk3ui-Bibliothek zu erstellen, die mit chrome/browser/ui/libgtk2ui/ übereinstimmt, und diese beiden Bibliotheken beim Start umzuschalten.

Und zum Zeitpunkt des Schreibens existiert libgtk3ui noch nicht :( Sie können sich auch den Code auf libgtk2ui ansehen.

Ich war zwischen persönlichen Laptops, nachdem ich dies ursprünglich gepostet hatte, und habe seitdem mein von der Firma ausgestelltes MBP für eine Handvoll Monate verwendet. Aber ich habe endlich meine neue Maschine, Ausfallzeiten und beschloss, einen Versuch damit zu machen. Meine bisherigen Fortschritte:

Ich war in der Lage, libchromiumcontent mit gtk3 zu erstellen, dies beinhaltete Folgendes:

• füge 'use_gtk3': 1 in chromiumcontent.gypi hinzu.
• sysroot deaktiviert, indem der Aufruf von install_sysroot() in script/update manuell auskommentiert wurde. Hinweis: Abhängig von der libchromiumcontent-Version müssen Sie möglicherweise use_sysroot in chromium/src/build/common.gypi auf 'use_sysroot': 0 . Ich gehe davon aus, dass der richtige Ansatz in Zukunft darin bestehen würde, zu debian_jessie zu wechseln, um die Fähigkeit zur Cross-Kompilierung in Builds zu erhalten?
• pkg-config ausgeführt:

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

• lief script/update -t x64 && script/build -t x64 && script/create-dist -t x64
• stundenlang gewartet :)

Leider war ich nach Abschluss des Builds jedoch etwas zu optimistisch und dachte, es sei ein Drag & Drop für einen Elektronenbau, aber das war es natürlich nicht. Ich denke, der nächste Schritt besteht darin, ein lokales Brightray aufzubauen und alle anderen Gyp-Dateien zu aktualisieren, um meine Systembibliotheken und nicht Sysroot zu verwenden.

Und in Bezug auf die libgtk2ui - ich habe Probleme, die Referenz zu finden, wo ich dies gelesen habe (vielleicht Gentoo-Foren, Chromium Issue Tracker oder ein Arch-Linux-Community-Thread) - aber ich glaube, dass Chromium die libgtk2ui unabhängig von gtk3/gtk2 erstellt, weil Die Entwickler haben das Nötigste getan, um einen Build mit GTK3 zum Laufen zu bringen. Ich könnte mich irren und ich weiß nicht, wie sich dies auf Electron-basierte Patches auswirken könnte, die speziell für gtk2 geschrieben wurden.

Ich mache einen wöchentlichen chromium-gtk3-Build für meinen persönlichen Browser und libgtk2ui ist immer noch vorhanden und ich gehe davon aus, dass es verwendet wird.

Ich werde hoffentlich in den nächsten Tagen hierher zurückkommen und auf meine POC-Repos mit vorgefertigten Binärdateien und einigen Bildschirmaufnahmen verlinken.

Fertig und ich habe atom-gtk3 hoffentlich bald einsatzbereit!

Die größte Hürde war, dass debian_wheezy_sysroot in libchromiumcontent/electron/brightray verwendet wurde. Betreuer dieser Repos werden wahrscheinlich einige Diskussionen führen und Entscheidungen treffen müssen, ob sie zu jessie wechseln oder sysroot möglicherweise optional machen.

Über das Wochenende werde ich versuchen, einen Knoten oder ein Bash-Skript zusammenzustellen, um eine verteilbare ausführbare Electron-GTK3-Datei zu erstellen. Ich glaube nicht, dass eine Pull-Anfrage, die ich stellen würde, akzeptiert wird, daher wird dies im Moment wahrscheinlich der effizienteste Weg für andere gtk3-Benutzer sein, den Build zu erhalten und zu verwenden. Und in den nächsten Wochen werde ich vielleicht sogar versuchen, einige AUR-Pakete für meine Arch-Benutzerkollegen zum Laufen zu bringen.

Dies waren die gtk3-Warnungen während des Elektronenbaus https://gist.github.com/nikolowry/05865698788d66ae0edfea2eb7c7fb0c

@nikolowry Gibt es eine Möglichkeit, Sysroot zu behalten, aber GTK+ 3.x in Sysroot zu kopieren?

@paulcbetts Ich denke, nur wenn Wheezy auf Jessie aktualisiert wird (ich könnte mich irren, aber ich würde wetten, dass Sie sich in der Abhängigkeitshölle befinden würden, wenn Sie versuchen würden, einfach gtk3 einzuschleusen). Zusätzlich zu gtk3 benötigen wir zum Erstellen von gtk3 auch die folgenden modernen Bibliotheken: wayland-protocols glib-2.0 gdk-3.0 gtk+-unix-print-3.0 .

Klingt super @nikolowry , danke für deine Arbeit. Ist der Quellcode irgendwo verfügbar? Ich würde gerne ein PPA fertig machen, um uns Ubuntu-Benutzern das Leben zu erleichtern.

Ich möchte noch hinzufügen, dass es bei diesem Thema nicht nur um die Bereitstellung moderner Widgets geht. GTK2 ist auf HiDPI-Systemen (zumindest nicht mit Ubuntu 16.04) nicht verwendbar, da alle Symbole in Schaltflächen und Symbolleisten extrem klein dargestellt sind. Glücklicherweise scheint dies in Atoms Fall nur den Datei-Öffnen-Dialog zu betreffen, zumindest soweit ich das sehen kann, so dass Atom selbst ziemlich brauchbar bleibt.

@EiNSTeiN Ich werde bis Ende des Wochenendes in Kürze auf ein Elektron-gtk3-Repo zurückgreifen.

Eine kleine Hintergrundgeschichte zuerst - der Hauptgrund, warum ich entschlossen war, dies zum Laufen zu bringen, war, dass ich Atom als meinen täglichen Treiber verwende und den Dateidialog nicht mehr sehen konnte! Dieser Build dauerte jedoch aufgrund von Komplikationen mit asar/compiled-cache/npm-not-running-post-install-scripts länger als erwartet, aber ich kann jetzt loslegen.

Ich habe darüber nachgedacht, wie dies am besten zu tun ist - also haben die Betreuer eine gute Referenz (es wäre schwierig, Pull-Requests in allen einzelnen Repos zu koordinieren) und auch, damit gtk3-Möchtegern-Benutzer als schnell unmöglich.

Aber ich werde keine automatisierten Builds durchführen, daher sollte jeder auf 4-6 Stunden Build-Zeiten oder die Vorbereitung einiger Server vorbereitet sein. Ich könnte am Ende gelegentlich eine Veröffentlichung vornehmen, bis diese Änderungen im offiziellen Repo widergespiegelt werden.

Ich habe mich darauf konzentriert, ein Repo mit Elektron als Untermodul zu erstellen und ein einzelnes Bash-Skript zum Erstellen von Elektron mit der ganzen Güte von GTK3 zu schreiben. Dann kann jede Distribution einen einfachen Ausgangspunkt für die Verteilung von Paketen haben, bis diese Änderungen tatsächlich offiziell sind.

Und auf die Hidpi-Notiz - mein exec cmd für atom-gtk3 ist GTK_THEME=Adwaita:dark GDK_SCALE=2 GDK_DPI_SCALE=.5 /usr/local/share/atom/atom --force-device-scale-factor=1.5 %U . Die GDK-Skalierungsflags fixieren auch die chromium-gtk3 ui-Schriftgröße. Hier sind einige Bildschirme von atom-gtk3 :

https://goo.gl/ydHspu

Hi,

Ich konnte Electron 1.1.2 mit GTK3 unter Arch Linux kompilieren, indem ich use_gtk3=1 an libchromiumcontent übergeben und gtk+-2.0 in gtk+-3.0 in brightray.gyp ändern konnte .

Jetzt stürzt die Standard-App von Electron ab, wenn ich eine Taste drücke.

Details hier: https://github.com/tensor5/arch-atom.

Das Build-Skript-Repository:
https://github.com/nikolowry/electron-gtk3

Hoffentlich ist es bis Ende der Woche fertig. Es ist ein WIP und baut noch nichts Sinnvolles auf.

@EiNSTeiN und @tensor5 - https://github.com/nikolowry/electron-gtk3 sollte jetzt bauen. Beachten Sie, dass es nur die Version release sei denn, Sie weisen es ausdrücklich an, sowohl debug als auch release zu erstellen. Lesen Sie die README-Datei und öffnen Sie ein Problem, wenn etwas nicht funktioniert.

@zcbenz Gibt es einen historischen Grund für die Verwendung von Debian Wheezy (ich weiß, dass Chromium gerne LTS-kompatibel ist)? Vielleicht ein Build-Flag hinzufügen, um Jessie/GTK3 zu verwenden? Ich könnte an einem richtigen Pull-Request arbeiten, wenn Sie die Idee nicht ablehnen, ansonsten haben Sie zumindest ein Referenz-Build-Skript, das erklärt, was es braucht, um GTK3 zum Bauen zu bringen.

Bearbeiten: @tensor5 verwenden Sie X oder Wayland? Ich weiß, dass Chromium gtk3-Builds bei wichtigen Eingabeereignissen in Wayland abstürzen.

@nikolowry : Ja, ich habe Wayland verwendet, und es funktioniert tatsächlich gut mit X, danke. Wissen Sie, ob dieses Chromium-Problem irgendwo diskutiert wurde?

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

@nikolowry Wir Build- Konfigurationen von Chromium, es gibt viele Linux-Distributionen und wir können nicht alle testen, während Chromium überall vollständig getestet wurde, sodass es sicher ist, Chromium zu folgen.

Ich finde es gut, ein Flag zum Build für GTK+3 hinzuzufügen, und das Hinzufügen eines Links zu Ihrem Build-Skript sieht für mich auch gut aus. Es kann Teil der fortgeschrittenen Themen der Linux-Build-Anleitung sein .

@zcbenz klingt gut - sie haben ein Python-Skript, das man ausführen könnte, das Jessie anstelle von Wheezy für Sysroot verwendet, aber ich denke, es ist am besten zu warten, bis es im Upstream-Chromium als Standard festgelegt ist.

Im Allgemeinen ist es eine gute Sache, gegen die älteste Distribution zu bauen, die Sie finden können, wenn es um die Verteilung von Software geht, da die Versionierung von glibc++ - das Upgrade auf Jessie könnte (obwohl ich es im Allgemeinen für viel sicherer halten würde) zu Waisen werden, die mit Electron arbeiten die Vergangenheit. Wir haben dieses Problem häufig bei RHEL-Benutzern angesprochen

@tensor5 hat herausgefunden, wie man in Wayland startet. Ich habe dieses Chromium-Ticket kommentiert und mein gtk3-Repository aktualisiert.

Sie müssen nur GDK_BACKEND=x11 electron ausführen, da Chromium sich nicht automatisch in das XWayland-Modul einklinkt.

@nikolowry FANTASTISCH!

Wenn ich das richtig verstehe, ist das Problem, dass GTK3 denkt, dass Elektron eine reine Wayland-Anwendung ist, während dies nicht der Fall ist.

@tensor5 genau! GTK3 geht davon aus, dass alle Apps, die das Toolkit verwenden, Wayland-fähig sind (und somit für das Laden von XWayland bei Bedarf verantwortlich sind).

Ich bereitete mich darauf vor, dieses Wochenende knietief in den Chromium-Quellcode einzusteigen, um es herauszufinden, und als ich versuchte, einige Protokolle zu generieren, stolperte ich über https://fedoraproject.org/wiki/How_to_debug_Wayland_problems über die einfache Lösung

Chromium und Atom waren meine letzten nicht-Wayland-fähigen Apps - ich bin froh, dass mein Skylake-Laptop nicht mehr über xrandr abstürzt, wenn er an mehrere Monitore im gemischten dpi-Modus angeschlossen ist!!!!

Bearbeiten: Ich weiß, dass Sie auch einige AUR-Pakete verwalten, also möchten Sie vielleicht die Desktop-Dateien bearbeiten, um "env GDK_BACKEND=x11" einzuschließen die Zukunft!

@nikolowry Ich bin schon dabei!

Irgendwann sollte dies in der Elektronenquelle behoben werden, die Verwendung eines Launcher-Skripts ist nicht der eleganteste Weg.

Übrigens, das AUR-Paket gehört nicht mir. Ich pflege ein Repository

@nikolowry Firefox ist auch eine GTK3-Anwendung, die auf Xwayland basiert, aber es funktioniert gut. Also habe ich es mir angeschaut : Wie Sie hier sehen können, versucht es zuerst das X11-Backend und verwendet dann den erkannten display_name für gdk_display_open .

Wahrscheinlich kann man in Chromium etwas Ähnliches machen.

Unter elementaren Betriebssystemen benötigen wir GTK3, um den pantheon-file-chooser zu verwenden, oder wir erhalten diese:

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

Warum nicht einfach Qt5-WebEngine unterstützen/portieren? es verwendet sowieso die chrom-Engine, und auf Qt sieht alles viel nativer aus als auf gtk ...

Außerdem ist qt5 nicht die ganze Zeit kaputt wie gtk3, das ihre F**king-APIs jedes Mal ändert, nur weil sie sich um nichts anderes als die Entwicklung von Gnomen kümmern.

Hier ist eine großartige Videopräsentation, warum gtk schlecht und qt besser ist (2 Jahre alt, aber immer noch gut und relevant)

Qt 5.6.x ist jetzt in LTS und ihre Lizenz wurde mit 5.7 geändert , das ist viel besser für Open-Source-Benutzer/-Entwickler

Ich persönlich verstehe nicht, warum Leute gtk außerhalb von Gnome-Zeug verwenden, wenn es dafür nicht entwickelt wurde.

@ahjolinna Eigentlich soll GTK+ auch für die Anwendungsentwicklung außerhalb von Gnome-Zeug verwendet werden. In jedem Fall wäre das Ändern der APIs auf QT ein Albtraum für das Electron-Team, da es viel Patching von Dingen aus dem Chromium-Upstream erfordern würde. Es ist die Mühe nicht wert.

GTK+3 _ist_ intrinsisch mit GNOME verheiratet, da im Grunde(?) alle GTK-Entwickler GNOME-Entwickler sind, die bei Red Hat beschäftigt sind.

Der erwähnte GTK-API-Bruch tritt auf, weil Red Hat das Vorantreiben von GNOME priorisiert. @ahjolinna hat Recht, dass Qt5 stabiler ist, _aber_ es nur eingeschränkten Zugriff auf die Chromium-Instanz bietet.

der grund ist auch die stabilität: chrom selbst bricht genug, dass sie ihre ressourcen nur in einigen bereichen einsetzen können, um ihre stabile API aufrechtzuerhalten.

@nikolowry Wenn ich https://github.com/nikolowry/electron-gtk3 verwenden würde , um ein Elektron mit gtk3-Unterstützung zu bauen, was müsste ich im Atom-Build ändern, um ein Atom-gtk3 zu bauen?

Für diejenigen, die einen gtk3-Build verwenden, sehen Sie wahrscheinlich weißen Text in der Menüleiste, wenn Sie ein helles Design verwenden. Dieser Patch behebt das Problem.

Ich werde die anderen gtk3-Build-Warnungen in den nächsten Tagen beheben.

Das Menü in Chromium mit Gtk2 ist nicht "nativer GTK-Stil" und sehr hässlich. Wird Gtk3-Build dies beheben?

@Menci. Nein, die Menüleiste bei gtk3 sieht genauso aus wie bei gtk2. Sie haben Recht, es ist nicht vollständig nativ, einfach die Farben von Text und Hintergrund folgen dem GTK-Thema.
Ich habe mir den Code in den letzten Tagen angeschaut, um zu sehen, ob das behoben werden könnte. Ein Problem besteht darin, dass nativer GTK-Code hinter Schichten von plattformübergreifenden Wrappern verborgen ist. Vielleicht können GTK-Experten da draußen helfen.

@tensor5 Ich denke, das Menü sollte in den plattformübergreifenden Wrappern implementiert werden. Genauso wie das Menü von OS X nativ ist und der native Cocoa-Code auch hinter Schichten von plattformübergreifenden Wrappern versteckt ist.

@Menci Natürlich ist dies die einzige Möglichkeit, einen solchen Patch zu akzeptieren.

Es wäre auch schön, ein Gnome-App-Menü zu haben.

Sie können sich ansehen, wie LibreOffice es gemacht hat, es ist auf ähnliche Weise.

Ich denke, die Menüs von LibreOffice sind nicht wirklich nativ. Sie haben keinen Schlagschatten und keine Animationen anzeigen / ausblenden.

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

GTK+-Apps sahen außerhalb von Gnome (und anderen GTK-Spinoffs) nie nativ aus, sie sahen auf KDE, LXQt immer schrecklich aus und Unity 8 wird das gleiche Problem haben, wenn es ankommt (es basiert auf Qt5). Das KDE-Team hat versucht, mit diesem Problem mit dem GTK-Team zusammenzuarbeiten, aber sie waren zu 100% Arschlöcher und es ist ihnen egal, dass sich ihre API mit jedem verdammten Update ändert / bricht und das (einige) KDE-Sachen wie das Breeze-GTk-Thema kaputt macht , was übrigens. musste wegen der dummen Argumentation von GTK-Teams hartcodiert werden.*

btw. mit KDE, LXQt und Unity 8 + Ubuntu Touch und SailfishOS ist der "Marktanteil" von Qt5 viel größer als gtk und das wird zumindest auf lange Sicht große Auswirkungen haben

PS. über libreoffice, Sie können es ohne GTK erstellen und mit dem nativen Filepicker haben, was zum Beispiel ChakraOS macht, PKGBUILD , warum? weil seine auf KDE/Qt fokussierte Distribution, die GTK so gut wie möglich vermeidet

bearbeitet

*GTK-Entwickler haben den Zugriff auf die Theme-Engines blockiert, die zuvor für die GTK-Integration in KDE verwendet wurden, daher besteht jetzt die einzige Möglichkeit darin, den "CSS-Weg" auszuprobieren.

einige Apps, die ich kenne, die Qt verwenden:
Dropbox, OBS, MEGA, VIber, Wireshark, makemkv, yacreader, masterpdfeditor, vapoursynth-editor, SVP, teamspeak3, mkvtoolnix-gui, hplip, scribus WPS-Office...

andere DE mit Qt5: http://papyros.io/ und https://lumina-desktop.org/

@ahjolinna Ich glaube, du versuchst, die falsche Menge zu überzeugen. Wenn Chromium den Wechsel nicht vornimmt, bezweifle ich stark, dass Electron den Wechsel vornehmen würde. Das Electron-Team zu bitten, dieses Projekt sowie eine QT5-Gabel von Chromium zu pflegen, ist zu viel verlangt.

Außerdem geht es bei diesem Problem darum, GTK2 durch GTK3 zu ersetzen. Wenn Sie möchten, dass sie einen Wechsel in Betracht ziehen, erstellen Sie bitte eine neue Ausgabe. Ansonsten ist es off Topic und füllt diesen Thread mit Lärm.

@alzadude Sie müssen einige der Grunt-Build-Skripte bearbeiten, damit das vorgefertigte Elektron nicht heruntergeladen wird Erinnerung gerade). Es ist nicht schwer, aber ich brauche immer eine Minute, wenn ich einen neuen Build mache, weil ich immer die paar Schritte vergesse, die ich im letzten vorherigen Build gemacht habe.

Wenn @tensor5 anfängt , gtk3 in seinem Arch-Atom-Repo zu verwenden, würde ich vorschlagen, das vielleicht auszuprobieren - ansonsten werde ich das nächste Mal wieder hier reinschauen, wenn ich das nächste Mal einen Build mache und die Änderungen für Sie dokumentiere (normalerweise mache ich sie auf dem Wochenende)

@nikolowry danke, einige dokumentierte Änderungen wären toll :)

Ich bin auf Fedora, also würde ich versuchen, die Änderungen basierend auf diesem Fedora-Copr zu integrieren:

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

Dieser Copr scheint derzeit einem Standardpaket auf Fedora am nächsten zu kommen. Es basiert auf diesen Upstream-RPM-Spezifikationsdateien:

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

Und wird in diesem Bugzilla-Bug erwähnt:

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

Basierend auf der bestehenden Arbeit würde ich möglicherweise versuchen, meinen eigenen Copr für gtk3-Builds von Electron und Atom zu erstellen (auf der Grundlage der dokumentierten Änderungen die Upstream-RPM-Spezifikationsdateien zu verzweigen, um die erforderlichen Patches zu integrieren). Es sei denn, jemand anderes schlägt mich natürlich :)

Ich versuche, ein Gentoo-Ebuild dafür zu schreiben, aber ohne Erfolg. Ich wäre sehr dankbar, wenn mir jemand dabei helfen würde.

@eternal-sorrow Hast du dir schon dev-util/electron angesehen, das Ebuild, das sich derzeit im offiziellen Gentoo-Baum befindet?

@devurandom , habe ich. Es ist eine sehr alte Version von Elektron (0.36.12). Ich habe es für die aktuelle Version (1.3.1) modifiziert, alle Patches angepasst, aber immer noch ein v8-Linking-Problem (viele undefinierte v8-Symbole) erhalten.

@ewige-kummer

1. Kontaktieren Sie [email protected] , den Betreuer dieses Pakets.
2. Richten Sie hier auf GH ein Overlay-Repo mit Ihrem Ebuild ein, vielleicht können wir es gemeinsam erarbeiten.

@eternal-sorrow in Arch Linux bauen wir

Gibt es diesbezüglich Fortschritte?

@nikolowry , welche Version von Atom und Elektron verwenden Sie in Ihrem Atom-gtk3? Mir wurde klar, dass aktuelle Versionen von Atomen Elektron-0,37 benötigen und mit aktuellen Versionen von Elektron nicht laufen können. Liege ich falsch?

@eternal-sorrow Atom wurde kürzlich auf eine neuere Version von Electron aktualisiert.

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

Gibt es eine Möglichkeit, gtk3 zu verwenden? Würde es vor allem für den besseren Dateidialog lieben.

Da archlinux bereits einen gtk3-Build hat, fehlt der Elektronenkern, um diesen zu haben?

Ich denke, sie wollen, dass der Wechsel stromaufwärts erfolgt. Und es ist jetzt offiziell geplant, siehe https://chromium.googlesource.com/chromium/src/+/acc4214c4dece4e70fb53355d557bd45f35965d6/docs/linux_gtk_theme_integration.md#GTK3.

Zusätzliche Informationen, Chromium / Google Chrome-Entwicklerkanäle verwenden GTK 3, also ist es jetzt nur eine Frage der Zeit.

Bestätigt für Chrome 59 unter https://bugs.chromium.org/p/chromium/issues/detail?id=79722#c110.

Jetzt nur noch eine Frage der Zeit...

Chrome 59 ist raus! :tada:

Jetzt, da Chrome 59 herauskommt, wäre es großartig, eine Electron-Vorabversion zu sehen, die mit GTK3 für Linux erstellt wurde.

Die GTK3-Unterstützung ist jetzt in Chromium stable (59), was bedeutet, dass sie bald in Electron unterstützt wird ! Als Linux-Neuling bin ich mit GTK3 nicht wirklich vertraut. Wenn ich diesen Thread durchlese und googele, stelle ich fest, dass dieses Upgrade das Erscheinungsbild von Menüs, Fenstern, Dialogen usw. verbessern wird. Ich denke, dies könnte ein Blog-würdiges Update sein, würde aber gerne mehr darüber erfahren, wie sich diese Änderung auf die Benutzer auswirkt.

Ich habe ein paar Fragen:

• Warum möchten Sie GTK3-Unterstützung?
• Ich sehe den "Dateidialog", der in diesem Thread häufig erwähnt wird. Was war in GTK2 daran falsch und wie wird es in GTK3 verbessert?
• Verbessert dieses Update Dinge wie Leistung, Kompatibilität usw.? Oder nur Benutzeroberfläche?
• Welche anderen Verbesserungen könnten die Leute erwarten?
• Welche Linux-Distributionen verwenden GTK(3)?

@zeke :

Warum möchten Sie GTK3-Unterstützung? Ich sehe den "Dateidialog", der in diesem Thread häufig erwähnt wird.

Eine Verbesserung, die mich interessiert, ist, dass Electron-Anwendungen, die in der Flatpak- Sandbox ausgeführt werden, jetzt nahtlos ein Portal zu einem Filechooser auf dem Host verwenden. Dies würde sogar das richtige Qt-Portal verwenden, wenn der Benutzer das Qt-Portal installiert hat.

Verbessert dieses Update Dinge wie Leistung, Kompatibilität usw.? Oder nur Benutzeroberfläche?

Theoretisch könnte die Hidpi-Unterstützung von Gtk3 relevant sein, aber ich weiß nicht, wie dies mit dem Rendering von Chromium interagiert, das das meiste davon umgehen würde. Es ändert sich also wahrscheinlich nur das Thema.

Welche Linux-Distributionen verwenden GTK(3)?

Effektiv haben alle Distributionen Gtk3. Unity, GNOME, MATE, Cinnamon, Budgie und schließlich XFCE verwenden Gtk3 als ihr wichtigstes Toolkit für Anwendungen.

@zeke

Welche Linux-Distributionen verwenden GTK(3)?

Alle großen Linux-Distributionen verwenden GTK3 für ihren Desktop (Shell). Einige haben auch eine KDE-Variante, aber die Standardeinstellung für alle ist GTK3.

Ich sehe den "Dateidialog", der in diesem Thread häufig erwähnt wird. Was war in GTK2 daran falsch und wie wird es in GTK3 verbessert?

Ja, obwohl GTK2- und GTK3-Anwendungen im selben System zusammenleben können, sind GTK3-Anwendungen besser in die aktuellen Desktops integriert. Der Dateiauswahldialog ist ein gutes Beispiel.

@zeke

Warum möchten Sie GTK3-Unterstützung?

Ich schätze Konsistenz – der Dateidialog ist bei GTK 3 ziemlich unterschiedlich, die Themen sind zwischen den GTK-Versionen oft etwas inkonsistent. Ich mag es auch, mein System minimal zu halten. Wenn Atom GTK 2 fallen lässt, bedeutet das einen Grund weniger, GTK 2 installiert zu haben.

Ich sehe den "Dateidialog", der in diesem Thread häufig erwähnt wird. Was war in GTK2 daran falsch und wie wird es in GTK3 verbessert?

Wie oben ist für mich die Konsistenz das Wichtigste. Der GTK 3-Dialog wird von einigen sogar als minderwertig angesehen, da er eine rekursive Namenssuche anstelle einer inkrementellen Suche im Verzeichnis verwendet.

Welche anderen Verbesserungen könnten die Leute erwarten?

Die Menüs sollten auch GTK verwenden, anstelle einer benutzerdefinierten Implementierung, die keine Mnemonik und das Springen zwischen benachbarten Menüs mit Pfeiltasten zu unterstützen scheint.

Atom Dropping GTK 2 bedeutet einen Grund weniger, GTK 2 installiert zu haben.

Nur damit ich verstehe, was Sie hier sagen, @jtojnar : Wenn Sie eine neuere Version von Linux haben, die standardmäßig GTK3 verwendet, müssen Sie GTK2 manuell installieren, um Apps zu unterstützen, die nicht auf GTK3 aktualisiert wurden? Welche anderen beliebten Apps haben neben Atom (und jeder anderen Electron-App) dieses Problem?

@zeke Die Installation von Abhängigkeiten wird normalerweise automatisch vom Paketmanager Ihrer Distribution durchgeführt. Bei der Installation der GTK 3-App wird auch libgtk3 heruntergeladen und die Installation der GTK 2-App erhält libgtk2 . Sie können sicher beide installiert haben, aber mit einer SSD, die wenig Speicherplatz hat, möchte ich jedes Legacy-Paket loswerden, das ich kann.

Warum möchten Sie GTK3-Unterstützung?

GTK3 ist neuer und hat HiDPI-Unterstützung.
GTK2 wird nicht mehr entwickelt und ist nicht modern.

Ich sehe den "Dateidialog", der in diesem Thread häufig erwähnt wird. Was war in GTK2 daran falsch und wie wird es in GTK3 verbessert?

Kenne diesen nicht.

Verbessert dieses Update Dinge wie Leistung, Kompatibilität usw.? Oder nur Benutzeroberfläche?

GTK3 soll einige CPU- und RAM-Funktionen besser ausnutzen, aber ich bin mir nicht sicher. Es wäre jedoch ein großes UI-Update.

Welche anderen Verbesserungen könnten die Leute erwarten?

Bessere Themenunterstützung.

Welche Linux-Distributionen verwenden GTK(3)?

Alle Distributionen haben GTK3 in ihren Repositories.
Viele große Desktop-Umgebungen verwenden GTK3, wie Gnome 3, Budgie, Deepin, MATE und bald(tm) XFCE.

Voraussetzung dafür ist Chromium 59, für das es einen Pull-Request für #9946 gibt.

@zeke Hauptziel ist eine bessere UI-Konsistenz, da Sie unter Linux höchstwahrscheinlich Apps sehen, die entweder GTK (2 oder 3) oder Qt als UI-Toolkit verwenden. Windows und macOS haben ihre eigenen und Sie werden normalerweise feststellen, dass die meisten Apps auf diesen Plattformen diese verwenden. Steam hat jedoch nicht dieses native Aussehen, da es beispielsweise nicht das native UI-Toolkit verwendet.

Ich sehe den "Dateidialog", der in diesem Thread häufig erwähnt wird. Was war in GTK2 daran falsch und wie wird es in GTK3 verbessert?

GTK2 im Vergleich zu GTK3 lässt sich am besten als frühere Versionen von Windows oder macOS erklären, bei denen die Benutzeroberfläche ein anderes visuelles Aussehen hatte (Layout-/Funktionsunterschiede von Dingen wie Dateibrowsern). Wenn Sie Windows 10 ausführen und ein Dateidialogfeld erhalten, das wie Windows Vista oder XP aussieht, sieht es fehl am Platz aus und es fehlen möglicherweise bestimmte Funktionen / UX.

Auf einer Desktop-Umgebung (DE) wie KDE erstellt dies immer noch einen GTK3-Dialog anstelle des üblicheren Toolkits für diese DE, Qt. Es gibt also immer noch einige Inkonsistenzen, aber es ist schöner als GTK2.

Hier sind einige Beispiele für KDE mit dem standardmäßigen Breeze-Theme:

GTK2 Dialog mit aktuellen Electron Apps - GitKraken:

GTK3-Dialog - Verschmelzen:

Qt-Dialog - Kate:

Mono/.NET(?) Dialog - BundleModder - Ungewöhnlich unter Linux, Java-Anwendungen können auch ein ungewöhnliches Toolkit verwenden:

Wie Sie sehen, ist die Stilkonsistenz bei den verschiedenen UI-Toolkits ziemlich unterschiedlich. Das kann für einen gelegentlichen Benutzer verwirrend sein, warum sie unterschiedlich sind, was dazu führt, dass Sie sich fragen, ob sie dem gleichen Zweck dienen, oder Frustration mit den unterschiedlichen Navigations- / Präsentationsdetails (GTK, auf das Sie möglicherweise doppelklicken, während Qt möglicherweise für Single eingerichtet ist). Klicken Sie auf Ordnernavigation) oder sehen Sie einfach die fehlende Konsistenz als unprofessionell an.

Gnome (GTK-fokussiertes DE) kann dies besser handhaben als KDE (Qt-fokussiertes DE) mit Konsistenz zwischen GTK3 und Qt, da das Toolkit von Qt so konzipiert ist, dass es sich plattformübergreifend gut integrieren lässt und ein natives Gefühl / Erlebnis vermittelt. GTK-Entwickler zögern, ihr Toolkit auf anderen DEs als Gnome zu unterstützen, obwohl KDE-Entwickler Code beisteuern wollen, um das Problem auf ihrer DE zu beheben. Wenn der Benutzer keine älteren Anwendungen verwendet, die GTK2 oder ungewöhnliche Toolkits verwenden, haben sie eine bessere Erfahrung.

Oft finden Sie eine Mischung aus GTK- und Qt-Apps, wenn ein Toolkit nicht so leistungsstark ist wie die andere Toolkit-Äquivalent-App Erfahrung, mit optionalen GTK-Apps wie Chrome verfügbar). Angesichts der Popularität von Electron-Anwendungen ist es nicht immer wünschenswert, GTK zu vermeiden.

Warum möchten Sie GTK3-Unterstützung?

Konsistenz, der Dateidialog sticht mir als KDE-Benutzer am meisten heraus.

Verbessert dieses Update Dinge wie Leistung, Kompatibilität usw.? Oder nur Benutzeroberfläche?
Welche anderen Verbesserungen könnten die Leute erwarten?

Obwohl ich nicht viel über FlatPak weiß (Sandbox-, distro-agnostische Apps, eine Art Docker/Container für GUI-Apps), denke ich, dass GTK3 dort eine bessere Geschichte hat als GTK2, einschließlich der Integration mit dem DE (FlatPak-Themen ist eine andere .) Story aus Konsistenzgründen, GTK3 in FlatPak hat kürzlich Theme-Unterstützung erhalten, andere Toolkits müssen dies ebenfalls hinzufügen). FlatPak kann, wie erwähnt, auch die Dateidialogprobleme über die Portalunterstützung lindern.

Ich weiß nicht viel über GTK2 vs GTK3 persönlich, aber die HiDPI-Geschichte wird für GTK3 besser sein, stelle ich mir vor (GTK2 bekommt vielleicht nicht einmal so etwas?). Theme-Unterstützung ist meiner Meinung nach besser, oder zumindest werden Sie in Zukunft eher Themes für GTK3 als 2 bekommen. Bei Gnome kann der Dateidialog etwas anders sein, da clientseitige Dekorationen (CSD) die UX für diese Benutzer verbessern. Auf KDE denke ich, dass die GTK3-Unterstützung mit der Global Menu-Funktion besser funktionieren könnte (immer noch WIP, macOS-ähnliche Menüleiste, anstatt an das Anwendungsfenster gebunden zu sein).

Welche Linux-Distributionen verwenden GTK(3)?

Die Mehrheit der modernen Distributionen verwendet GTK3 oder unterstützt es, soweit ich weiß. GTK2 ist ziemlich alt. Wenn Sie Chrome- oder Electron-Apps verwenden, verwenden Sie GTK (wahrscheinlich eine Mischung aus 2/3, aber eher in Richtung 3).

@polarathene , Sie haben nicht erwähnt, dass die GTK3-Unterstützung das Hinzufügen von Wayland-Unterstützung in Zukunft ermöglicht, während dies bei GTK2 nicht der Fall ist.

Der JFYI Chromium GTK2-Build ist im neuesten stabilen 60.0.3112.90 und in der Beta 61.0.3163.31 defekt.
Es funktioniert jedoch im neuesten Master.

Und übrigens, es wird nicht mehr offiziell gepflegt.
https://groups.google.com/a/chromium.org/d/msg/chromium-dev/iO3qzex6oYA/Q-i4Cie3BwAJ

Fantastisches Feedback zu den Tugenden von GTK3, jeder. Danke für deinen Beitrag.

Leider hört es sich so an, als würde das GTK3-Update nicht in Electron 1.8 mit Chrome 59 landen. Es blockiert derzeit den Build, daher müssen wir bis zum nächsten Chromium-Bump auf 61 warten (wir überspringen 60), bevor GTK3 unterstützt wird im Elektron.

Stimmt das, @alexeykuzmin?

@zeke haben Sie eine grobe Schätzung, wann die Chrom-61-Beule auftreten wird? Wir möchten unseren Wechsel zu nativen ES6-Webkomponenten planen, um ihn an dieser Version auszurichten. Historisch gesehen kommen die Beulen einen Monat oder so nach der Veröffentlichung?

@zeke
Ja, wir hatten einige Probleme mit dem GTK3 im Chromium 59-Zweig.
Aber wir sollten im kommenden Chromium 61-Upgrade von GTK2 auf GTK3 umsteigen.

@cpoole Wir haben derzeit keine Schätzung, wann Chromium 61 in Electron landen wird, aber es wird derzeit in https://github.com/electron/libchromiumcontent/pull/335 daran gearbeitet. Unser Ziel ist es, mit den Chromium-Releases schließlich besser Schritt zu halten. Einige großartige Leute von Microsoft ( @tonyganch , @cifratila , @alexeykuzmin , @alespergl , andere?) Also ich bin optimistisch :)

Warum möchten Sie GTK3-Unterstützung?

@deikatsuo Welcher Browser ist das? Es sieht so aus, als hätten Chrom und Epiphanie ein Baby...

@mdsitton epiphany

Gibt es darüber irgendwelche Neuigkeiten?

@ziggy42 sollte es schon im neusten Chrom 61 (https://github.com/electron/electron/pull/10213) geben. Ich denke, es geht nur darum, in Master zu fusionieren und irgendwann eine Veröffentlichung zu machen.

Kann es kaum erwarten, diese hässlichen Dateipicker brennen mir in die Augen :fire:

Erlaubt diese Änderung CSS in Electron-Apps?

Also, Chrom 61 ist verschmolzen, soll gtk3 mitkommen?

Electron verwendet jetzt GTK3 im Master-Zweig, wird im nächsten Minor/Major-Release ausgeliefert.

@ahjolinna

Danke, dass Sie etwas Verstand in diese Diskussion investieren.

KaOS, das bereits erwähnt wurde, könnte Sie wirklich interessieren.
Es wird von der Person gepflegt, die Chakra mehrere Jahre lang großartig gemacht hat, IMHO.

@alle

Wann wurde GTK+ 3 veröffentlicht?

vor 7 Jahren.

Lassen Sie das eine Weile im Mund zergehen.

Und ein riesiger Haufen Softwareprojekte sitzt immer noch auf 2.
Da das Portieren ein Vergnügen ist..

XFCE, Mate und viele andere brauchten 6 Jahre, um den Code zu portieren.
Andere Projekte wurden innerhalb von 2 komplett von GTK auf Qt umgestellt.

Und ja: GTK+ wird von GNOME entwickelt, sogar das Repo sitzt dort.
Es ist - von Natur aus und definitionsgemäß - für GNOME und sonst nichts entwickelt.

Qt wurde für die echte und native Integration in mehrere Plattformen entwickelt.

Elektron ist was?

Ein GNOME-Shop?

Schön.

Kluges Denken.

Es ist das gleiche wie in der imperativen und funktionalen Programmierung, aber auch in so vielen anderen Aspekten hier in dieser Szene: Redundante, alte, veraltete Software wird oft als Suchtmittel behandelt, was sie zu einer macht.

Und neue, clevere, innovative Software wird mit Missverständnissen und purer Ignoranz behandelt.

10, 12 Projekte wechselten von GTK+ zu Qt, während ich keinen einzigen Fall kenne, bei dem es umgekehrt war.

Lassen Sie sich das noch einmal auf der Zunge zergehen: Das bedeutet eine komplette Neufassung ihres gesamten, integrierten UI-Codes.
Oft tief verschachtelt.

Das bedeutet, dass sie dies im Vergleich zu einem größeren Upgrade ihres bestehenden Tools bevorzugen.
Und alle sind mit dieser Entscheidung bis heute glücklich.

Frag sie.

Bevor Sie der Herde folgen, ohne über Alternativen nachzudenken.

@ahjolinna hat euch ein Video von einer dieser Personen gepostet, VLC, Wireshark, LXQt und andere bemerkenswerte Softwareprojekte basieren ebenfalls früher auf GTK.

GTK wird in Chromium nur als Bindung an Aura verwendet und dies nur unter Linux/freeBSD/Solaris und so weiter:
Windows- und macOS-Builds sind davon kostenlos.

:zwinkern:

Obwohl ich Ihre Punkte @ShalokShalom bekomme , müssen Sie nicht unhöflich sein, Electron folgt dem, was vom Chromium-Team geliefert wird.

Der Gabelknopf ist übrigens oben, fühlen Sie sich frei.

Ja, das war unnötig aggressiv.

Aber ich stimme zu. GTK hat zu viele unnötige Brüche, die Schmerzen verursachen, Qt wäre die bessere Wahl gewesen

• WENN QtWebEngine genügend Zugriff auf die zugrunde liegende Chromium-Instanz bietet
• WENN QtWebEngine das neueste Chromium schnell genug verfolgt

Ich schlage vor, dass wir die Diskussion an einen geeigneteren Ort verlagern. @ShalokShalom , wie wenn Sie hier einfach ein neues Thema eröffnen und das Problem

Auch VLC , Wireshark, LXQt und andere bemerkenswerte Softwareprojekte basieren früher auf GTK.

Das stimmt nicht. VLC verwendete vor Qt wxWidgets, nicht GTK: https://wiki.videolan.org/WxWidgets_Interface/

Mir scheint, GTK-Leute haben seit geraumer Zeit eingeräumt, dass sie in der 3.x-Serie Bruch und Versionierung nicht gut genug kommuniziert haben und sich in Zukunft mit besserer und klarerer Langzeitstabilität bemühen werden, wie unter https:/ nachzulesen ist.

Ich würde auch sagen, dass Qt und GTK aufgrund unterschiedlicher Geschichte, Unterstützung und Ziele nicht fair verglichen werden können und meiner Meinung nach beide Vor- und Nachteile haben, je nach Sichtweise.

Zu behaupten, GTK sei für und nur für das GNOME-Projekt gemacht, ist meiner Meinung nach auch eine unfaire Pauschalaussage.

Ha! Ich wusste wirklich nichts von diesen Plänen. scheint, als hätten sie endlich gelernt. Hoffen wir, dass sie anfangen, jede bahnbrechende Änderung in CSS als echte bahnbrechende Änderung zu betrachten.

das letzte was ich gehört habe war das… ähm… exzentrische GTK 4.0 ist nicht GTK 4 . so kommen sie endlich zu etwas fast so gutem wie semver! sie machen fast so gut wie Qt vor 20 Jahren! 😁

Wir sollten Electron bald standardmäßig mit nativer GTK3-Unterstützung sehen, basierend auf diesem Twitter-Post :

Electron 2.0.0-beta.1 ist mit aktualisiertem Chromium und Node.js, macOS-In-App-Käufen, GTK3-Unterstützung für Linux und vielem mehr erhältlich.

Jawohl. Die eigentliche Arbeit dafür wurde von den Chromium-Autoren geleistet und Electron hat sie durch das Chromium-Upgrade in Electron 2.0.0 erhalten.

Darüber hinaus wurde Electrons eigener Code in https://github.com/electron/electron/pull/11879 GTK3ifiziert

Ja, das war unnötig aggressiv.
Aber ich stimme zu. GTK hat zu viele unnötige Brüche, die Schmerzen verursachen, Qt
wäre die bessere wahl gewesen
WENN QtWebEngine genügend Zugriff auf die zugrunde liegende Chromium-Instanz bietet
WENN QtWebEngine das neueste Chromium schnell genug verfolgt

Nun, das ist das Hauptproblem. Die Leute überlegen, was für sie am schnellsten zu implementieren ist, was in Ordnung ist, während sie sehr oft vergessen, dass die eigentliche Implementierung, um es zum Laufen zu bringen, etwas ganz anderes ist als die langfristige Wartung.

Es ist aus meiner Sicht glasklar, dass die genannten Probleme angegangen werden können.

Wenn Sie die Anzahl der Programmierer, die tatsächlich an GTK3-Ports arbeiten, mit denen vergleichen, die ihren gesamten UI-Code auf ein neues Toolkit portieren, können Sie sehen, wie erstaunlich der Unterschied ist. Ich glaube, ich habe bereits ein Video dazu gepostet mit dem Titel "Von GTK zu Qt: Eine seltsame Reise".

Warum sich auf veraltete Software konzentrieren, nur weil sie einsatzbereit scheint, anstatt den Support in Qt zu hacken?

Es ist das 'Ich benutze das, was _scheinbar_ bereit ist'-Dogma, das langfristige Entscheidungen völlig ignoriert. Ja, es mag zunächst so aussehen, als ob es etwas mehr Aufwand erfordert, während Sie sicherlich von dem modernen Toolkit profitieren, wenn es einmal implementiert ist.

Es ist auch nicht so drastisch, dass QtWebEngine Chrome nicht so schnell folgt:
Es ist schnell genug und Qupzilla beweist, dass man damit erstaunliche Dinge anstellen kann - insbesondere in einer geeigneten Umgebung wie KaOS.

Glauben Sie wirklich, dass Sie "mehr Zugriff auf das zugrunde liegende Chromium" brauchen und "QtWebEngine Chromium nicht schnell genug folgt", da Qupzilla und andere Software sich als erstaunliche Software herausstellen, die von einem einzigen Programmierer verwaltet wird?

Sie glauben, dass Sie als vollwertiger Webbrowser in Electron mehr Zugriff und schnelleres Folgen benötigen? Wie so?

Jetzt sitzt man in so vielen Projekten auf diesem plumpen Software-Stack und kleine Teams schaffen es, 40-60% ihres tief verschachtelten Codes schnell und effizient nach Qt zu portieren;

Etwas, das sie von GTK 2 bis GTK 3 nicht geschafft haben, was ziemlich erstaunlich ist. Wie gesagt: Die meisten Projekte brauchten 6-7 Jahre, um eine Hauptversion zu

Und das scheint fast jeder zu ignorieren? Es ist so traurig, dass sich in einer ursprünglich wissenschaftlichen Gemeinschaft immer noch so primitive Entscheidungen ausbreiten.

Frieden :)

@ShalokShalom , was meinst du mit "veraltete Software"? GTK+? Gibt es einen Grund, warum Sie das sagen?

Bitte stoppen Sie mit diesem Qt-Spam, dies ist ein Problem mit dem GTK 3-Port. Wenn Sie das Bedürfnis haben, Betreuer davon zu überzeugen, zu Qt zu wechseln, öffnen Sie ein separates Problem. Ich möchte Neuigkeiten über den Implementierungsfortschritt erhalten, keine Nachrichten von Qt-Fanboys.

Diese Konversation wird aufgrund einer übermäßigen Diskussion außerhalb des Themas gesperrt.

Das Sperren behebt nur ein Symptom, ist aber eine vernünftige schnelle Lösung, da der Wechsel zu GTK3 abgeschlossen ist und es nicht mehr viel zu besprechen gibt, was das Thema des Wechsels von GTK2 zu GTK3 betrifft.