Electron: Pertimbangkan untuk mengganti GTK2 w GTK3 di Linux build

Kedengarannya bagus untuk saya setelah kami meningkatkan ke Chrome 47.

Chrome 47 dirilis tiga hari lalu. :) http://googlechromereleases.blogspot.se/2015/12/stable-channel-update.html

Menggali sedikit tetapi masih tidak yakin di mana harus meletakkan flag use_gtk3 ..

@zcbenz atau bisakah Anda memberi kami petunjuk di mana harus meletakkannya?

Saya bukan ahli dalam membangun perilaku di balik sistem pembangunan untuk Chromium, tetapi membaca dari bug terkait Chromium di sana , sebaiknya kita menambahkannya ke variables ke common.gypi . Baris yang relevan ada di sini .

Sebenarnya saya sedang menguji pada kotak Linux untuk itu juga. Kotak pengembangan saya saat ini menjalankan Elementary OS , dan setiap kali aplikasi Gtk2 dijalankan, ia akan menampilkan peringatan Gtk-Message: Failed to load module "pantheon-filechooser-module" ( Ref ). Jika semuanya berjalan lancar (semoga) mari kita lihat apakah saya bisa mendapatkan PR juga. Pasti akan menyukai masukan Anda di sana.

Ada pembaruan tentang ini? Sebagai pengguna atom saya ingin melihatnya menggunakan GTK3 bukan GTK2.

@netsgnut apakah itu berfungsi dengan baik?

apa artinya "%"?

perubahannya cuma ini?

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,

Ada berita ? Dialog file terbuka GTK2 cukup merepotkan untuk digunakan!

@flying-sheep Ah, maaf untuk keheningan radio yang lama. Telah berkomitmen untuk proyek lain di luar GitHub, buruk.

Kembali ke kasus kami, itulah yang awalnya saya pikir harus berfungsi, tetapi secara misterius gagal membangun aplikasi Gtk3 yang tepat di kotak saya. Dalam kasus saya, niat awal saya adalah membuat build Electron yang tidak akan mengeluarkan kesalahan di bawah kotak pengembangan saya (yang menjalankan Elementary OS Freya). Namun tampaknya membangun seperti itu tidak akan benar-benar membuat peringatan itu hilang.

di #4642, @zcbenz berkata:

Bendera use_gtk3 hanya bermakna di bawah sisi Chromium, untuk mengaktifkan GTK3 kita harus mengaktifkannya di libchromiumcontent terlebih dahulu, lalu mengubah pengaturan tautan di Electron.

jadi apa sebenarnya yang perlu dilakukan?

1. aktifkan menggunakan GTK3 di libchromiumcontent: apakah menambahkan flag di chromiumcontent.gypi sudah cukup? apakah ini penting atau apakah elektron tidak menggunakan build target itu?
2. ubah pengaturan tautan di Electron: di mana melakukan ini?

Saya bukan ahli di bidang ini, dan tidak yakin apakah saya salah memahami komentar @zcbenz ; hanya 2 sen saya.

Mengenai pertanyaan:

1. Mungkin tidak. libchromiumcontent tampaknya, dari tampilannya, sekumpulan skrip yang mengunduh sumber chromium dari upstream , patches , dan repackage untuk digunakan di Atom. Selain mengubah tanda pada chromiumcontent.gypi seperti yang telah Anda sebutkan, setidaknya pustaka dependensi juga dikemas dengan benar . Lihat contoh libgtk2ui .
2. Ada fragmen di Electron yang merujuk ke UI khusus libgtk2 . Mereka menunjuk ke ketergantungan dalam kromium (dan/atau turunannya). "Tautan" seperti dalam komentar @zcbenz mungkin merujuk pada itu.

Bug pelacakan di Chromium mencerminkan semacam status dari hulu. Salah satu komentator mencatat:

IIRC, itu akan membutuhkan membangun perpustakaan libgtk3ui agar sesuai dengan chrome/browser/ui/libgtk2ui/, dan kedua perpustakaan ini diaktifkan pada saat startup.

Dan, pada saat penulisan, libgtk3ui belum ada :( Anda juga dapat melihat kode di libgtk2ui.

Saya berada di antara laptop pribadi setelah saya memposting ini dan telah menggunakan MBP yang dikeluarkan perusahaan saya selama beberapa bulan sejak itu. Tapi saya akhirnya memiliki mesin baru saya, downtime dan memutuskan untuk mencoba ini. Kemajuan saya sejauh ini:

Saya bisa mendapatkan libchromiumcontent untuk dibangun dengan gtk3, itu memerlukan yang berikut:

• tambahkan 'use_gtk3': 1 di chromiumcontent.gypi.
• menonaktifkan sysroot dengan secara manual mengomentari panggilan untuk install_sysroot() dalam skrip/pembaruan. Catatan: Bergantung pada versi libchromiumcontent, Anda mungkin perlu menyetel use_sysroot di chromium/src/build/common.gypi ke 'use_sysroot': 0 . Saya berasumsi pendekatan yang tepat di masa depan adalah beralih ke debian_jessie untuk kemampuan kompilasi silang dalam build?
• menjalankan 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

• berlari script/update -t x64 && script/build -t x64 && script/create-dist -t x64
• menunggu berjam-jam :)

Namun, sayangnya saya agak terlalu optimis setelah build selesai, berpikir itu adalah drag n' drop untuk build elektron, tapi tentu saja tidak. Saya pikir langkah selanjutnya adalah membangun brightray lokal dan file gyp apa pun yang diperbarui untuk menggunakan lib sistem saya dan bukan sysroot.

Dan sehubungan dengan libgtk2ui - saya mengalami kesulitan menemukan referensi ke tempat saya membaca ini (mungkin forum gentoo, pelacak masalah chromium atau utas komunitas linux arch) - tetapi saya percaya bahwa Chromium membangun libgtk2ui terlepas dari gtk3/gtk2 karena para pengembang melakukan minimal untuk membuat build dengan gtk3 berfungsi. Saya bisa saja salah dan saya tidak tahu bagaimana hal ini dapat mempengaruhi patch berbasis Elektron yang ditulis khusus untuk gtk2.

Saya melakukan build chromium-gtk3 mingguan untuk browser pribadi saya dan libgtk2ui masih ada dan saya berasumsi digunakan.

Saya akan kembali ke sini semoga dalam beberapa hari ke depan dan menautkan ke repo POC saya dengan binari bawaan dan beberapa tangkapan layar.

Selesai dan semoga atom-gtk3 saya akan segera aktif!

Rintangan terbesar adalah debian_wheezy_sysroot digunakan di seluruh libchromiumcontent/electron/brightray. Pengelola repo tersebut mungkin perlu berdiskusi dan membuat keputusan apakah akan beralih ke jessie atau mungkin membuat sysroot opsional.

Selama akhir pekan saya akan mencoba dan mengumpulkan skrip node atau bash untuk membuat executable electron gtk3 yang dapat didistribusikan. Saya tidak berpikir permintaan tarik apa pun yang saya buat akan diterima, jadi untuk saat ini mungkin ini akan menjadi cara yang paling efisien bagi sesama pengguna gtk3 untuk mendapatkan dan menggunakan build. Dan selama beberapa minggu ke depan saya bahkan mungkin mencoba untuk mendapatkan beberapa paket AUR untuk sesama pengguna Arch saya.

Ini adalah peringatan gtk3 selama pembuatan elektron https://Gist.github.com/nikolowry/05865698788d66ae0edfea2eb7c7fb0c

@nikolowry Apakah ada cara bagi kita untuk menyimpan sysroot tetapi menyalin di GTK+ 3.x ke dalam sysroot?

@paulcbetts Saya pikir hanya jika Wheezy ditingkatkan ke Jessie (saya bisa saja salah tetapi saya berani bertaruh Anda akan menemukan diri Anda dalam neraka ketergantungan jika Anda mencoba menyelinap gtk3 di sana). Selain gtk3, kita juga memerlukan lib modern berikut untuk gtk3 untuk membangun: wayland-protocols glib-2.0 gdk-3.0 gtk+-unix-print-3.0 .

Kedengarannya luar biasa @nikolowry , terima kasih atas pekerjaan Anda. Apakah kode sumber tersedia di suatu tempat? Saya ingin PPA siap untuk membuat hidup lebih mudah bagi kami pengguna Ubuntu.

Saya juga ingin menambahkan bahwa masalah ini bukan hanya soal penyediaan widget modern. GTK2 tidak dapat digunakan pada sistem HiDPI (setidaknya tidak dengan ubuntu 16.04) karena semua ikon di tombol dan bilah alat ditampilkan sangat kecil. Untungnya dalam kasus Atom ini tampaknya hanya mempengaruhi dialog buka file, setidaknya sejauh yang saya bisa lihat, jadi Atom itu sendiri tetap cukup bisa digunakan.

@EiNSTeiN Saya akan segera menautkan kembali ke repo electron-gtk3 pada akhir akhir pekan.

Sedikit latar belakang pertama - alasan utama mengapa saya bertekad untuk menjalankan ini adalah karena saya menggunakan Atom sebagai driver harian saya dan tidak tahan melihat dialog file lagi! Namun, pembuatan itu memakan waktu lebih lama dari yang diharapkan karena komplikasi dengan skrip asar/compiled-cache/npm-not-running-post-install-script, tapi saya baik-baik saja sekarang.

Saya telah memikirkan cara terbaik untuk melakukan ini - jadi pengelola akan memiliki referensi yang baik (akan sulit mengoordinasikan permintaan tarik di semua repo individu) dan juga agar gtk3-calon-pengguna bisa bangun dan berjalan sebagai cepat tidak mungkin.

Tapi saya tidak akan melakukan build otomatis, jadi semua orang harus bersiap untuk waktu build 4-6 jam atau untuk menyiapkan beberapa server. Saya mungkin akhirnya melakukan rilis sesekali sampai perubahan ini tercermin dalam repo resmi.

Saya telah mempersempit membuat repo dengan elektron sebagai submodul dan menulis skrip bash tunggal untuk membangun elektron dengan semua kebaikan gtk3. Kemudian setiap distro dapat memiliki titik awal yang mudah untuk akhirnya mendistribusikan paket sampai perubahan ini benar-benar di resmikan.

Dan ke catatan hidpi - cmd exec saya untuk atom-gtk3 adalah GTK_THEME=Adwaita:dark GDK_SCALE=2 GDK_DPI_SCALE=.5 /usr/local/share/atom/atom --force-device-scale-factor=1.5 %U . Bendera skala GDK juga memperbaiki ukuran font chromium-gtk3 ui. Berikut beberapa tampilan dari atom-gtk3 :

https://goo.gl/ydHspu

Hai,

Saya dapat mengkompilasi Electron 1.1.2 dengan GTK3 di Arch Linux, meneruskan use_gtk3=1 ke libchromiumcontent dan mengubah gtk+-2.0 menjadi gtk+-3.0 di brightray.gyp .

Sekarang aplikasi default Electron mogok setiap kali saya menekan tombol.

Detailnya di sini: https://github.com/tensor5/arch-atom.

Repo skrip build:
https://github.com/nikolowry/electron-gtk3

Mudah-mudahan minggu ini sudah selesai. Ini adalah WIP dan belum membangun sesuatu yang berarti.

@EiNSTeiN dan @tensor5 - https://github.com/nikolowry/electron-gtk3 harus dibangun sekarang. Perhatikan bahwa itu hanya membangun versi release kecuali Anda secara khusus memerintahkannya untuk membangun debug dan release . periksa README dan buka masalah jika ada yang tidak berfungsi.

@zcbenz apakah ada alasan historis dalam menggunakan Debian Wheezy (saya tahu Chromium suka kompatibel dengan LTS)? Mungkin menambahkan flag build untuk menggunakan Jessie/GTK3? Saya dapat mengerjakan permintaan tarik yang tepat jika Anda tidak menentang gagasan tersebut, jika tidak, Anda setidaknya memiliki skrip pembuatan referensi tentang apa yang diperlukan untuk membuat GTK3 dibangun.

Sunting: @ tensor5 apakah Anda menggunakan X atau Wayland? Saya tahu build chromium gtk3 mogok pada acara input utama di Wayland.

@nikolowry : ya saya menggunakan Wayland, dan memang berfungsi dengan baik dengan X, terima kasih. Tahukah Anda jika masalah Chromium ini telah dibahas di suatu tempat?

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

@nikolowry Kami hanya mengikuti konfigurasi bangunan Chromium, ada banyak distribusi Linux dan kami tidak dapat menguji semuanya, sementara Chromium sepenuhnya diuji di mana-mana, jadi aman untuk mengikuti Chromium.

Saya baik-baik saja menambahkan flag untuk membangun GTK+3, dan menambahkan tautan ke skrip build Anda juga terlihat bagus bagi saya. Ini dapat menjadi bagian dari topik lanjutan dari instruksi pembuatan Linux .

@zcbenz terdengar bagus - mereka memiliki skrip python yang dapat dijalankan yang menggunakan Jessie alih-alih Wheezy untuk sysroot, tapi saya rasa yang terbaik adalah menunggunya ditetapkan sebagai default di Chromium hulu.

Secara umum, membangun distro tertua yang dapat Anda temukan adalah Hal yang Baik dalam hal mendistribusikan perangkat lunak karena versi glibc++ - peningkatan ke Jessie dapat (meskipun saya akan menganggapnya jauh lebih aman secara umum) orang yatim piatu yang telah bekerja di Electron masa lalu. Kami sering mengalami masalah ini dengan pengguna RHEL

@ tensor5 menemukan cara meluncurkan di Wayland. Saya mengomentari tiket Chromium itu dan memperbarui repo gtk3 saya.

Hanya perlu menjalankan GDK_BACKEND=x11 electron karena Chromium tidak terhubung ke modul XWayland secara otomatis.

@nikolowry LUAR BIASA !

Jadi jika saya mengerti dengan benar, masalahnya adalah GTK3 menganggap elektron adalah aplikasi Wayland murni, padahal tidak.

@tensor5 tepatnya! GTK3 mengasumsikan semua aplikasi yang menggunakan toolkit sudah Wayland ready (sehingga bertanggung jawab untuk memuat XWayland jika diperlukan).

Saya sedang bersiap untuk masuk ke dalam kode sumber Chromium akhir pekan ini untuk mengetahuinya, dan ketika saya mencoba membuat beberapa log, saya menemukan solusi sederhana melalui https://fedoraproject.org/wiki/How_to_debug_Wayland_problems.

Chromium dan Atom adalah aplikasi terakhir saya yang tidak siap-Wayland - sangat senang laptop Skylake saya tidak akan mogok melalui xrandr lagi ketika dihubungkan ke multi-monitor dalam mode dpi campuran!!!!

Sunting: Saya tahu Anda juga memelihara beberapa paket AUR, jadi Anda mungkin ingin mengedit file desktop untuk menyertakan "env GDK_BACKEND=x11", itu akan memungkinkan aplikasi berjalan di X dan Wayland dan menghemat banyak sakit kepala orang lain di masa depan!

@nikolowry saya sudah melakukannya!

Akhirnya ini harus diperbaiki di sumber elektron, menggunakan skrip peluncur bukanlah cara yang paling elegan.

BTW paket AUR bukan milik saya. Saya memelihara repositori

@nikolowry Firefox juga merupakan aplikasi GTK3 yang mengandalkan Xwayland, tetapi berfungsi dengan baik. Jadi saya melihatnya: seperti yang Anda lihat di sini, ia mencoba backend X11 terlebih dahulu, dan kemudian menggunakan display_name yang terdeteksi untuk gdk_display_open .

Mungkin hal serupa bisa dilakukan di Chromium.

Pada OS dasar kita membutuhkan GTK3 untuk menggunakan pantheon-file-chooser, atau kita akan mendapatkan ini:

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

mengapa tidak mendukung/port ke Qt5-WebEngine saja ? tetap menggunakan mesin chromium, dan di Qt semuanya terlihat jauh lebih asli tidak seperti di gtk...

ditambah qt5 tidak rusak sepanjang waktu seperti gtk3 yang mengubah API F**king mereka setiap saat hanya karena mereka tidak peduli dengan hal lain selain pengembangan gnome.

di sini adalah presentasi video yang bagus mengapa gtk buruk dan qt lebih baik (berusia 2 tahun tetapi masih bagus dan relevan)

Qt 5.6.x sekarang di LTS dan lisensinya diubah dengan 5.7 , itu jauh lebih baik untuk pengguna/pengembang open source

Saya pribadi tidak mengerti mengapa orang menggunakan gtk di luar hal-hal gnome, ketika itu tidak dirancang untuk itu.

@ahjolinna Sebenarnya GTK+ dimaksudkan untuk digunakan untuk pengembangan aplikasi di luar hal-hal Gnome juga. Mengubah API ke QT akan menjadi mimpi buruk bagi tim Electron karena akan membutuhkan banyak perbaikan dari hulu Chromium. Itu tidak sebanding dengan kesulitannya.

GTK+3 _is_ secara intrinsik menikah dengan GNOME, karena pada dasarnya(?) semua pengembang GTK adalah pengembang GNOME, dipekerjakan oleh topi merah.

kerusakan GTK API yang disebutkan terjadi karena topi merah memprioritaskan mendorong GNOME ke depan. @ahjolinna benar bahwa Qt5 lebih stabil, _but_ hanya menyediakan akses terbatas ke instance chromium.

alasannya juga stabilitas: chromium itu sendiri cukup rusak sehingga mereka hanya dapat melakukan sumber daya mereka untuk mempertahankan API stabil mereka di beberapa area.

@nikolowry jika saya menggunakan https://github.com/nikolowry/electron-gtk3 untuk membangun elektron dengan dukungan gtk3, apa yang perlu saya ubah dalam pembuatan atom untuk membangun atom-gtk3?

Bagi mereka yang menggunakan gtk3 build, Anda mungkin melihat teks putih di bilah menu saat menggunakan tema ringan. Patch ini memecahkan masalah.

Saya akan memperbaiki peringatan build gtk3 lainnya di hari-hari berikutnya.

Menu di Chromium dengan Gtk2 bukan 'gaya gtk asli', dan sangat jelek. Akankah Gtk3 build memperbaikinya?

@Menci. Tidak, bilah menu dengan gtk3 terlihat persis sama dengan gtk2. Anda benar, ini tidak sepenuhnya asli, hanya warna teks dan latar belakang mengikuti tema gtk.
Saya melihat kode dalam beberapa hari terakhir, untuk melihat apakah itu bisa diperbaiki. Satu masalah adalah bahwa kode gtk asli tersembunyi di balik lapisan pembungkus lintas platform. Mungkin pakar gtk di luar sana dapat membantu dengan ini.

@ tensor5 Saya pikir menu harus diimplementasikan dalam pembungkus lintas platform. Sama seperti menu OS X asli dan kode Kakao asli juga tersembunyi di balik lapisan pembungkus lintas platform.

@Menci Tentu saja, itu satu-satunya cara agar tambalan semacam itu dapat diterima.

Akan menyenangkan juga memiliki menu aplikasi Gnome.

Anda dapat melihat bagaimana LibreOffice melakukannya, dengan cara yang serupa.

Saya pikir menu LibreOffice tidak benar-benar asli. Mereka tidak memiliki drop shadow dan menampilkan/menyembunyikan animasi.

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

Aplikasi GTK+ tidak pernah terlihat asli di luar gnome (dan spin-off gtk lainnya), mereka selalu terlihat mengerikan di KDE, LXQt) dan Unity 8 akan memiliki masalah yang sama ketika tiba (berbasis Qt5). Tim KDE telah mencoba bekerja dengan tim gtk dengan masalah ini, tetapi mereka telah menyelesaikan 100% bajingan dan mereka tidak peduli bahwa API mereka berubah/putus dengan setiap pembaruan sialan dan itu akan merusak (beberapa) hal-hal KDE seperti tema angin-gtk , yang btw. harus di-hardcode karena alasan bodoh tim gtk.*

Omong-omong. dengan KDE, LXQt dan Unity 8 + Ubuntu Touch dan SailfishOS, "pangsa pasar" Qt5 menjadi jauh lebih besar daripada gtk dan itu akan memiliki pengaruh besar setidaknya dalam jangka panjang

PS. tentang libreoffice, Anda dapat membangunnya tanpa GTK dan menggunakan filepicker asli, ini yang dilakukan ChakraOS misalnya, PKGBUILD , mengapa? karena distro fokus KDE/Qt-nya yang suka menghindari penggunaan GTK sebanyak mungkin

diedit

*Pengembang GTK memblokir akses ke mesin tema, yang sebelumnya digunakan untuk integrasi GTK di KDE, jadi sekarang satu-satunya cara adalah mencoba "cara CSS"

beberapa aplikasi yang saya tahu yang menggunakan Qt:
Dropbox, OBS, MEGA, VIber, Wireshark, makemkv, yacreader, masterpdfeditor, vapoursynth-editor, SVP, teamspeak3, mkvtoolnix-gui, hplip, scribus WPS-office...

DE lain menggunakan Qt5: http://papyros.io/ dan https://lumina-desktop.org/

@ahjolinna Saya pikir Anda mencoba meyakinkan orang yang salah. Jika Chromium tidak beralih maka saya sangat ragu Electron akan beralih. Meminta tim Electron untuk mempertahankan proyek ini serta fork QT5 dari Chromium meminta terlalu banyak.

Selain itu, masalah ini adalah tentang mengganti GTK2 dengan GTK3. Jika Anda ingin mereka mempertimbangkan untuk beralih, silakan buat masalah baru. Kalau tidak, itu di luar topik dan mengisi utas ini dengan kebisingan.

@alzadude Anda harus mengedit beberapa skrip build kasar sehingga tidak mengunduh elektron prebuilt, edit versi package.json agar sesuai dengan build elektron yang Anda lakukan secara lokal dengan gtk3 dan mungkin satu atau dua edit python (maaf keluar memori sekarang). Itu tidak sulit tetapi selalu membutuhkan waktu beberapa menit ketika saya melakukan build baru karena sepertinya saya selalu melupakan beberapa langkah yang saya ambil di build sebelumnya.

Jika @ tensor5 mulai menggunakan gtk3 dalam repo arch-atom-nya, saya sarankan untuk mencobanya - jika tidak, saya akan kembali ke sini saat berikutnya saya membuat dan mendokumentasikan perubahan untuk Anda (biasanya lakukan di akhir pekan)

@nikolowry terima kasih, beberapa perubahan yang terdokumentasi akan sangat bagus :)

Saya di Fedora jadi saya ingin memasukkan perubahan berdasarkan Fedora copr ini:

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

Copr ini tampaknya saat ini menjadi hal yang paling dekat dengan paket standar di Fedora. Ini didasarkan pada file spesifikasi rpm hulu ini:

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

Dan disebutkan dalam bug Bugzilla ini:

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

Berdasarkan pekerjaan yang ada, saya mungkin akan membuat Copr saya sendiri, untuk build gtk3 dari Electron dan Atom (membagi file spesifikasi rpm hulu untuk memasukkan tambalan yang diperlukan, berdasarkan perubahan yang didokumentasikan). Kecuali orang lain mengalahkan saya untuk itu tentu saja :)

Saya mencoba menulis ebuild gentoo untuk ini, tetapi tidak berhasil. Saya akan sangat berterima kasih, jika seseorang membantu saya melakukan ini.

@eternal-sorrow Apakah Anda sudah melihat dev-util/electron, ebuild yang saat ini ada di pohon resmi Gentoo?

@devurandom , saya lakukan. Ini versi elektron yang sangat lama (0.36.12). Saya memodifikasinya untuk versi saat ini (1.3.1), mengadaptasi semua tambalan, tetapi masih mendapatkan masalah penautan v8 (banyak simbol v8 yang tidak ditentukan).

@keabadian-kesedihan

1. Hubungi [email protected] , pengelola paket itu.
2. Siapkan repo overlay dengan ebuild Anda di sini di GH, mungkin kita bisa menyelesaikannya bersama.

@eternal-sorrow di Arch Linux kami membangun Electron versi terbaru dengan GTK3 , lihatlah.

Ada kemajuan dalam hal ini?

@nikolowry , versi atom dan elektron mana yang Anda gunakan di atom-gtk3 Anda? Saya menyadari bahwa versi atom saat ini membutuhkan elektron-0,37 dan tidak dapat berjalan dengan versi elektron saat ini. Apakah aku salah?

@eternal-sorrow Atom baru-baru ini diperbarui ke versi Electron yang lebih baru.

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

Apakah ada cara untuk menggunakan gtk3? Akan menyukainya terutama untuk dialog file yang lebih baik.

Karena archlinux sudah memiliki build gtk3, apa yang hilang dari ini adalah inti elektron?

Saya pikir mereka ingin peralihan terjadi di hulu. Dan secara resmi direncanakan sekarang, lihat https://chromium.googlesource.com/chromium/src/+/acc4214c4dece4e70fb53355d557bd45f35965d6/docs/linux_gtk_theme_integration.md#GTK3.

Info tambahan, saluran dev chromium/google chrome menggunakan gtk 3 jadi tinggal menunggu waktu saja.

Dikonfirmasi untuk Chrome 59 di https://bugs.chromium.org/p/chromium/issues/detail?id=79722#c110.

Hanya masalah waktu sekarang...

Chrome 59 keluar! :tada:

Sekarang setelah Chrome 59 keluar, akan sangat bagus untuk melihat pra-rilis Electron yang dibuat dengan GTK3 untuk Linux.

Dukungan GTK3 sekarang dalam Chromium stable (59), yang berarti akan segera didukung di Electron ! Sebagai pemula Linux, saya tidak begitu akrab dengan GTK3. Membaca utas ini dan googling, saya menyimpulkan bahwa peningkatan ini akan meningkatkan tampilan menu, jendela, dialog, dll. Saya pikir ini mungkin pembaruan yang layak untuk blog, tetapi ingin tahu lebih banyak tentang bagaimana perubahan ini memengaruhi pengguna.

Saya punya beberapa pertanyaan:

• Mengapa Anda menginginkan dukungan GTK3?
• Saya melihat "dialog file" banyak disebutkan di utas ini. Apa yang salah dengan GTK2 dan bagaimana peningkatannya di GTK3?
• Apakah pembaruan ini meningkatkan hal-hal seperti kinerja, kompatibilitas, dll? Atau UI saja?
• Apa perbaikan lain yang mungkin diharapkan orang?
• Distro Linux apa yang menggunakan GTK(3)?

@zeke :

Mengapa Anda menginginkan dukungan GTK3? Saya melihat "dialog file" banyak disebutkan di utas ini.

Satu peningkatan yang saya minati adalah bahwa aplikasi Electron yang berjalan di dalam kotak pasir Flatpak sekarang akan dengan mulus menggunakan portal ke pemilih file di host. Ini bahkan akan menggunakan Qt yang benar jika pengguna telah menginstal portal Qt.

Apakah pembaruan ini meningkatkan hal-hal seperti kinerja, kompatibilitas, dll? Atau UI saja?

Secara teori, dukungan hidpi dari Gtk3 mungkin relevan tetapi saya tidak tahu bagaimana ini berinteraksi dengan rendering Chromium yang akan melewati sebagian besar dari itu. Jadi mungkin hanya mengubah tema.

Distro Linux apa yang menggunakan GTK(3)?

Secara efektif semua distro memiliki Gtk3. Unity, GNOME, MATE, Cinnamon, Budgie, dan akhirnya XFCE menggunakan Gtk3 sebagai toolkit utama mereka untuk aplikasi.

@zeke

Distro Linux apa yang menggunakan GTK(3)?

Semua distro Linux utama menggunakan GTK3 untuk desktop (shell). Beberapa juga memiliki rasa KDE tetapi default untuk semuanya adalah GTK3.

Saya melihat "dialog file" banyak disebutkan di utas ini. Apa yang salah dengan GTK2 dan bagaimana peningkatannya di GTK3?

Ya, meskipun aplikasi GTK2 dan GTK3 dapat hidup bersama dalam sistem yang sama, aplikasi GTK3 lebih terintegrasi dengan desktop saat ini. Dialog File Chooser adalah salah satu contoh yang bagus.

@zeke

Mengapa Anda menginginkan dukungan GTK3?

Saya menghargai konsistensi – dialog file sangat berbeda pada GTK 3, tema seringkali sedikit tidak konsisten antara versi GTK. Saya juga suka menjaga sistem saya minimal, Atom menjatuhkan GTK 2 berarti satu alasan lebih sedikit untuk menginstal GTK 2.

Saya melihat "dialog file" banyak disebutkan di utas ini. Apa yang salah dengan GTK2 dan bagaimana peningkatannya di GTK3?

Seperti di atas, bagi saya yang terpenting adalah konsistensi. Dialog GTK 3 sebenarnya dianggap lebih rendah oleh beberapa orang, karena menggunakan pencarian nama rekursif daripada pencarian tambahan di direktori.

Apa perbaikan lain yang mungkin diharapkan orang?

Menu juga harus menggunakan GTK, alih-alih implementasi khusus yang tampaknya tidak mendukung mnemonik dan melompat di antara menu yang berdekatan menggunakan tombol panah.

Atom menjatuhkan GTK 2 berarti satu alasan lebih sedikit untuk menginstal GTK 2.

Supaya saya mengerti apa yang Anda katakan di sini, @jtojnar : Jika Anda memiliki versi Linux yang lebih baru yang menggunakan GTK3 secara default, maka Anda harus menginstal GTK2 secara manual untuk mendukung aplikasi yang belum diperbarui ke GTK3? Selain Atom (dan setiap aplikasi Electron lainnya), aplikasi populer apa lagi yang memiliki masalah ini?

@zeke Instalasi dependensi biasanya dilakukan secara otomatis oleh manajer paket distribusi Anda, menginstal aplikasi GTK 3 juga akan mengunduh libgtk3 dan menginstal aplikasi GTK 2 akan mendapatkan libgtk2 . Anda dapat menginstal keduanya dengan aman, hanya saja dengan ruang SSD yang rendah, saya ingin menyingkirkan setiap paket lama yang saya bisa.

Mengapa Anda menginginkan dukungan GTK3?

GTK3 lebih baru dan memiliki dukungan HiDPI.
GTK2 tidak dikembangkan lagi dan tidak modern.

Saya melihat "dialog file" banyak disebutkan di utas ini. Apa yang salah dengan GTK2 dan bagaimana peningkatannya di GTK3?

Tidak tahu tentang yang satu ini.

Apakah pembaruan ini meningkatkan hal-hal seperti kinerja, kompatibilitas, dll? Atau UI saja?

GTK3 dikatakan lebih memanfaatkan beberapa fitur CPU dan RAM, tapi saya tidak yakin sebaliknya. Ini akan menjadi pembaruan UI yang besar.

Apa perbaikan lain yang mungkin diharapkan orang?

Dukungan tema yang lebih baik.

Distro Linux apa yang menggunakan GTK(3)?

Semua distro memiliki GTK3 di repositori mereka.
Banyak lingkungan desktop utama menggunakan GTK3, seperti Gnome 3, Budgie, Deepin, MATE dan segera (tm) XFCE juga.

Prasyarat untuk ini adalah Chromium 59 yang ada pull request untuk #9946.

@zeke Main takeaway adalah konsistensi UI yang lebih baik karena di Linux Anda kemungkinan besar melihat aplikasi menggunakan GTK (2 atau 3) atau Qt sebagai toolkit UI. Windows dan macOS memilikinya sendiri dan Anda biasanya akan menemukan sebagian besar aplikasi di platform tersebut menggunakannya, Steam tidak memiliki tampilan asli itu misalnya karena tidak menggunakan toolkit UI asli.

Saya melihat "dialog file" banyak disebutkan di utas ini. Apa yang salah dengan GTK2 dan bagaimana peningkatannya di GTK3?

GTK2 dibandingkan dengan GTK3 mungkin paling baik dijelaskan sebagai versi Windows atau macOS sebelumnya di mana UI memiliki tampilan visual yang berbeda (perbedaan tata letak/fungsi seperti browser file). Jika Anda menjalankan Windows 10 dan mendapatkan dialog file yang terlihat seperti Windows Vista atau XP, itu akan terlihat tidak pada tempatnya dan mungkin kekurangan fitur/UX tertentu.

Pada lingkungan desktop (DE) seperti KDE, ini masih membuat dialog GTK3 alih-alih toolkit yang lebih umum untuk DE itu, Qt. Jadi masih ada beberapa inkonsistensi di sana, tapi lebih bagus dari GTK2.

Berikut adalah beberapa contoh pada KDE dengan tema Breeze default:

Dialog GTK2 dengan aplikasi Electron saat ini - GitKraken:

Dialog GTK3 - Perpaduan:

Dialog Qt - Kate:

Mono/.NET(?) Dialog - BundleModder - Tidak umum di Linux, aplikasi Java juga dapat menggunakan toolkit yang tidak umum:

Seperti yang Anda lihat, konsistensi gaya sangat berbeda di seluruh toolkit UI yang berbeda. Itu dapat membingungkan sebagai pengguna biasa mengapa mereka berbeda, membuat Anda bertanya-tanya apakah mereka untuk tujuan yang sama atau frustrasi dengan detail navigasi/presentasi yang berbeda di antara mereka (GTK Anda dapat mengklik dua kali, sementara Qt mungkin diatur untuk satu klik navigasi folder) atau hanya melihat kurangnya konsistensi sebagai tidak profesional.

Gnome (DE fokus GTK) mampu menangani ini lebih baik daripada KDE (DE fokus Qt) dengan konsistensi antara GTK3 dan Qt, karena toolkit Qt dirancang untuk berintegrasi lintas platform dengan baik memberikan nuansa/pengalaman asli. Pengembang GTK enggan mendukung toolkit mereka di DE selain Gnome, meskipun pengembang KDE ingin menyumbangkan kode untuk mengatasi masalah di DE mereka. Jika pengguna tidak menggunakan aplikasi lama yang menggunakan GTK2 atau toolkit yang tidak umum, mereka akan memiliki pengalaman yang lebih baik.

Seringkali Anda akan menemukan campuran aplikasi GTK dan Qt ketika toolkit tidak memiliki penawaran yang kuat seperti aplikasi lain yang setara dengan toolkit, untuk beberapa pengguna hanya menggunakan satu aplikasi toolkit yang layak (KaOS adalah distro yang melayani Qt5 pengalaman, dengan aplikasi GTK opsional seperti Chrome tersedia). Dengan popularitas aplikasi Electron, menghindari GTK tidak selalu diinginkan.

Mengapa Anda menginginkan dukungan GTK3?

Konsistensi, dialog file menjadi salah satu yang paling menonjol bagi saya sebagai pengguna KDE.

Apakah pembaruan ini meningkatkan hal-hal seperti kinerja, kompatibilitas, dll? Atau UI saja?
Apa perbaikan lain yang mungkin diharapkan orang?

Meskipun saya tidak tahu banyak tentang FlatPak (kotak pasir, aplikasi distro-agnostik, semacam Docker/wadah untuk aplikasi GUI), saya pikir GTK3 memiliki cerita yang lebih baik di sana daripada GTK2, termasuk integrasi dengan DE (tema FlatPak adalah yang lain cerita untuk konsistensi, GTK3 di FlatPak baru-baru ini mendapat dukungan tema, toolkit lain perlu menambahkan ini juga). FlatPak seperti yang disebutkan juga dapat meringankan masalah dialog file melalui dukungan portalnya.

Saya tidak tahu terlalu banyak tentang GTK2 vs GTK3 secara pribadi, tetapi cerita HiDPI akan lebih baik untuk GTK3 yang saya bayangkan (GTK2 bahkan mungkin tidak mendapatkan seperti itu?). Dukungan tema saya kira lebih baik, atau setidaknya Anda lebih mungkin mendapatkan tema untuk GTK3 daripada 2 terutama di masa mendatang. Di Gnome, dialog file mungkin sedikit berbeda dengan dekorasi sisi klien (CSD) yang meningkatkan UX untuk pengguna tersebut. Pada KDE saya pikir dukungan GTK3 mungkin bekerja lebih baik dengan fitur Menu Global (masih WIP, macOS seperti bilah menu daripada terikat ke jendela aplikasi).

Distro Linux apa yang menggunakan GTK(3)?

Mayoritas distro modern menggunakan GTK3 atau mendukungnya sejauh yang saya tahu. GTK2 sudah cukup tua. Jika Anda menggunakan aplikasi Chrome atau Electron, Anda menggunakan GTK (mungkin campuran 2/3, tetapi lebih condong ke arah 3).

@polarathene , Anda tidak menyebutkan bahwa dukungan GTK3 memungkinkan untuk menambahkan dukungan Wayland di masa mendatang, sedangkan GTK2 tidak.

JFYI Chromium GTK2 build rusak di stabil terbaru 60.0.3112.90 dan dalam beta 61.0.3163.31.
Ini berfungsi di master terbaru.

Dan btw, itu tidak dipertahankan secara resmi lagi.
https://groups.google.com/a/chromium.org/d/msg/chromium-dev/iO3qzex6oYA/Q-i4Cie3BwAJ

Umpan balik yang luar biasa tentang keunggulan GTK3, semuanya. Terima kasih atas masukan Anda.

Sayangnya sepertinya pembaruan GTK3 tidak akan mendarat di Electron 1.8 dengan Chrome 59. Saat ini sedang memblokir build, jadi kami harus menunggu hingga Chromium berikutnya ke 61 (kami melewatkan 60) sebelum GTK3 didukung di Elektron.

Apakah itu benar, @alexeykuzmin?

@zeke apakah Anda memiliki perkiraan kasar kapan benjolan kromium 61 akan terjadi? Kami ingin merencanakan perpindahan kami ke komponen web ES6 asli untuk menyelaraskan dengan rilis itu. Secara historis benjolan datang sebulan atau lebih setelah rilis?

@zeke
Ya, kami memiliki beberapa masalah dengan GTK3 di cabang Chromium 59.
Tetapi kita harus beralih dari GTK2 ke GTK3 dalam peningkatan Chromium 61 yang akan datang.

@cpoole saat ini kami tidak memiliki perkiraan kapan Chromium 61 akan mendarat di Electron, tetapi sedang dikerjakan sekarang di https://github.com/electron/libchromiumcontent/pull/335. Tujuan kami adalah untuk menjadi lebih sejalan dengan rilis Chromium. Beberapa orang hebat dari Microsoft ( @tonyganch , @cifratila , @alexeykuzmin , @alespergl , others?) telah membantu dalam proses itu, yang membebaskan tim Electron GitHub untuk fokus pada peningkatan CI dan memperlancar proses rilis Elektron. Jadi saya optimis :)

Mengapa Anda menginginkan dukungan GTK3?

@deikatsuo Browser apa itu? Sepertinya chrome dan pencerahan punya bayi...

@mdsitton pencerahan 👍

Ada berita tentang ini?

@ziggy42 seharusnya sudah ada di chromium 61 terbaru (https://github.com/electron/electron/pull/10213). Saya kira itu hanya masalah penggabungan master dan membuat rilis di beberapa titik.

Tidak sabar, pemetik file jelek itu membakar mata saya :fire:

Akankah perubahan ini memungkinkan CSS di aplikasi Electron?

Jadi, chromium 61 digabung, haruskah gtk3 ikut?

Electron sekarang menggunakan GTK3 di cabang master, akan dikirimkan dalam rilis minor/mayor berikutnya.

@ahjolinna

Terima kasih bahwa Anda menghabiskan beberapa kewarasan pada diskusi ini.

Anda mungkin sangat tertarik dengan KaOS, yang telah disebutkan sebelumnya.
Itu dikelola oleh orang yang membuat Chakra hebat selama beberapa tahun, IMHO.

@semua

GTK+ 3 rilis kapan?

7 tahun yang lalu.

Biarkan itu meleleh di mulut Anda untuk sementara waktu.

Dan banyak proyek perangkat lunak masih duduk di 2.
Karena porting adalah kesenangan..

XFCE, Mate, dan banyak lainnya membutuhkan waktu 6 tahun untuk mem-porting kode tersebut.
Proyek lain beralih sepenuhnya dari GTK ke Qt dalam waktu 2.

Dan ya: GTK+ dikembangkan oleh GNOME, bahkan repo ada di sana.
Ini - secara alami dan definisi - dikembangkan untuk GNOME dan tidak ada yang lain.

Qt dikembangkan untuk integrasi yang benar dan asli ke dalam beberapa platform.

Elektron itu apa?

Toko GNOME?

Bagus.

Pemikiran yang cerdas.

Ini sama seperti dalam pemrograman imperatif dan fungsional, serta dalam banyak aspek lain di sini dalam adegan ini: Perangkat lunak yang berlebihan, lama, dan ketinggalan zaman sering diperlakukan sebagai obat adiktif, yang membuatnya menjadi satu.

Dan perangkat lunak baru, pintar, inovatif diperlakukan oleh kesalahpahaman dan ketidaktahuan murni.

10, 12 proyek beralih dari GTK+ ke Qt sementara saya tidak tahu satu kasus pun, di mana sebaliknya terjadi.

Biarkan ini meleleh di lidah Anda lagi: Itu berarti penulisan ulang lengkap dari keseluruhan kode UI terintegrasi mereka.
Sangat bersarang, sering.

Yang berarti mereka lebih suka itu, dibandingkan dengan peningkatan besar dari alat mereka yang ada.
Dan mereka semua senang dengan keputusan itu, sampai hari ini.

Tanya mereka.

Sebelum Anda mengikuti kawanan tanpa mempertimbangkan alternatif.

@ahjolinna memposting Anda video salah satu dari orang-orang ini, VLC, Wireshark, LXQt dan proyek perangkat lunak luar biasa lainnya juga sebelumnya didasarkan pada GTK.

GTK hanya digunakan di Chromium sebagai pengikat ke Aura dan ini hanya di Linux/freeBSD/Solaris dan seterusnya:
Windows dan macOS build bebas dari itu.

:mengedip:

Meskipun saya mendapatkan poin Anda @ShalokShalom , tidak perlu kasar, Electron mengikuti apa yang disampaikan oleh tim Chromium.

Tombol garpu ada di atas btw, silakan.

Ya, ini tidak perlu abrasif.

Tapi saya setuju. GTK memiliki terlalu banyak kerusakan yang tidak perlu yang menyebabkan rasa sakit, Qt akan menjadi pilihan yang lebih baik

• JIKA QtWebEngine menyediakan akses yang cukup ke instans chromium yang mendasarinya
• JIKA QtWebEngine melacak Chromium terbaru dengan cukup cepat

Saya sarankan kita pindahkan diskusi ke tempat yang lebih tepat. @ShalokShalom , bagaimana kalau Anda membuka masalah baru di sini dan menjelaskan masalahnya dengan cara yang lebih sopan daripada yang Anda lakukan sekarang?

VLC , Wireshark, LXQt dan proyek perangkat lunak luar biasa lainnya juga sebelumnya didasarkan pada GTK.

Itu tidak benar. VLC menggunakan wxWidgets sebelum Qt, bukan GTK: https://wiki.videolan.org/WxWidgets_Interface/

Bagi saya, orang-orang GTK telah cukup lama mengakui bahwa mereka tidak mengomunikasikan kerusakan dan versi dengan cukup baik di seri 3.x dan akan berusaha lebih keras di masa depan dengan stabilitas jangka panjang yang lebih baik dan lebih jelas seperti yang dapat dibaca di https:/ /blog.gtk.org/2016/09/01/versioning-and-long-term-stability-promise-in-gtk/.

Saya juga akan mengatakan bahwa Qt dan GTK tidak dapat dibandingkan secara adil satu per satu karena sejarah, dukungan, dan tujuan yang berbeda dan menurut saya keduanya memiliki pro dan kontra tergantung pada sudut pandang Anda.

Menyatakan bahwa GTK dibuat untuk dan hanya untuk proyek GNOME juga menurut saya merupakan pernyataan yang tidak adil.

Ha! Aku benar-benar tidak tahu tentang rencana itu. sepertinya mereka akhirnya belajar. mari berharap mereka mulai mempertimbangkan setiap perubahan yang melanggar di CSS sebagai perubahan yang nyata.

hal terakhir yang saya dengar adalah ... umm ... excentric GTK 4.0 bukan GTK 4 . jadi akhirnya sampai pada sesuatu yang hampir sebagus semver! mereka melakukan hampir sebagus Qt 20 tahun yang lalu! 😁

Kita akan segera melihat Electron dengan dukungan GTK3 asli secara default berdasarkan posting twitter ini:

Electron 2.0.0-beta.1 keluar dengan Chromium dan Node.js yang diperbarui, pembelian dalam aplikasi macOS, dukungan GTK3 untuk Linux , dan banyak lagi.

Ya. Pekerjaan nyata untuk ini dilakukan oleh penulis Chromium dan Electron mendapatkannya melalui peningkatan Chromium di Electron 2.0.0.

Selain itu, kode Electron sendiri mendapat GTK3ified di https://github.com/electron/electron/pull/11879

Ya, ini tidak perlu abrasif.
Tapi saya setuju. GTK memiliki terlalu banyak kerusakan yang tidak perlu yang menyebabkan rasa sakit, Qt
akan menjadi pilihan yang lebih baik
JIKA QtWebEngine menyediakan akses yang cukup ke instance chromium yang mendasarinya
JIKA QtWebEngine melacak Chromium terbaru dengan cukup cepat

Nah, ini masalah utamanya. Orang-orang mempertimbangkan apa yang tercepat untuk diterapkan bagi mereka, yang baik-baik saja, sementara mereka sangat sering lupa bahwa implementasi aktual untuk menjalankannya adalah sesuatu yang sangat berbeda dari pemeliharaan jangka panjang.

Jelas dari sudut pandang saya, bahwa masalah yang disebutkan dapat diatasi.

Setelah Anda membandingkan jumlah pembuat kode yang benar-benar bekerja pada port GTK3 dan mereka yang mem-porting seluruh kode UI mereka pada toolkit baru, dapatkah Anda melihat betapa menakjubkan perbedaannya. Saya rasa saya sudah memposting video tentangnya, berjudul 'Dari GTK ke Qt: Perjalanan yang aneh.'

Mengapa berfokus pada perangkat lunak usang, hanya karena tampaknya siap digunakan, alih-alih meretas dukungan di Qt?

Itu adalah dogma 'Saya menggunakan apa yang _tampaknya_ siap', yang sepenuhnya mengabaikan keputusan jangka panjang. Ya, mungkin terlihat seperti itu membutuhkan sedikit lebih banyak usaha di tempat pertama, sementara kalian pasti mendapat manfaat dari toolkit modern setelah diimplementasikan.

Ini juga tidak terlalu drastis, bahwa QtWebEngine tidak mengikuti Chrome secepat itu:
Cukup cepat dan Qupzilla membuktikan bahwa Anda dapat melakukan hal-hal luar biasa dengannya - terutama di lingkungan yang sesuai, seperti KaOS.

Apakah Anda benar-benar berpikir bahwa Anda memerlukan 'lebih banyak akses ke Chromium yang mendasarinya' dan bahwa 'QtWebEngine tidak cukup cepat mengikuti Chromium' karena Qupzilla dan perangkat lunak lain terbukti mengirimkan perangkat lunak luar biasa, yang dikelola oleh satu pembuat kode?

Anda pikir Anda membutuhkan lebih banyak akses dan pengikut yang lebih cepat sebagai browser web lengkap di Electron? Bagaimana?

Sekarang, Anda duduk di tumpukan perangkat lunak yang canggung ini di begitu banyak proyek dan tim kecil berhasil mem-port 40-60% kode mereka yang sangat bersarang ke Qt dengan cepat dan efisien;

Sesuatu yang tidak berhasil mereka lakukan dari GTK 2 hingga GTK 3, yang cukup menakjubkan. Seperti yang dikatakan: Sebagian besar proyek membutuhkan waktu 6-7 tahun untuk meningkatkan versi utama

Dan hampir semua orang tampaknya mengabaikan itu? Sangat menyedihkan, bahwa dalam komunitas yang awalnya ilmiah, keputusan yang begitu primitif terus menyebar.

Perdamaian :)

@ShalokShalom , apa yang Anda maksud dengan "perangkat lunak usang"? GTK+? Ada alasan kamu mengatakan itu?

Tolong hentikan spam Qt ini, ini adalah masalah tentang port GTK 3. Jika Anda merasa perlu meyakinkan pengelola untuk beralih ke Qt, buka edisi terpisah. Saya ingin menerima berita tentang kemajuan implementasi, bukan pesan dari Qt fanboys.

Mengunci percakapan ini karena diskusi di luar topik yang berlebihan.

Penguncian hanya mengatasi gejala, tetapi merupakan perbaikan cepat yang masuk akal karena perpindahan ke GTK3 sudah selesai dan tidak banyak yang tersisa untuk didiskusikan tentang topik perpindahan dari GTK2 ke GTK3 ini.