Electron: LinuxビルドでGTK2とGTK3を置き換えることを検討してください

作成日 2015年09月28日  ·  100コメント  ·  ソース: electron/electron

Googleは最近、「use_gtk3」ビルドフラグをChormiumに追加しました-export GYP_DEFINES = "$ GYP_DEFINES use_gtk3 = 1"。

GTK3デスクトップのほとんどのエンドユーザーは、最新のウィジェットを使用することを好むと思います。 デフォルトとして追加するには時期尚早かもしれませんが、最終的には素晴らしいです。

Chromium 47 w gtk3のビデオ:
https://www.youtube.com/watch?v=TJidbdaHCYc

これは、私が開いた古い問題にいくらか関連しています。
https://github.com/atom/electron/issues/765

enhancement platforlinux

最も参考になるコメント

Electronは現在マスターブランチでGTK3を使用しており、次のマイナー/メジャーリリースで出荷されます。

全てのコメント100件

Chrome 47にアップグレードした後は、良さそうです。

Chrome47は3日前にリリースされました。 :) http://googlechromereleases.blogspot.se/2015/12/stable-channel-update.html

少し掘り下げましたが、use_gtk3フラグをどこに置くかまだわかりません。

@zcbenzまたはそれをどこに置くかについてのポインタを教えていただけますか?

私はChromiumのビルドシステムの背後にあるビルド動作の専門家ではありませんが、Chromium関連のバグを読んでvariablesからcommon.gypiに追加しても問題ありません。 関連する行はここにあります

実際、私もLinuxボックスでテストしています。 私の現在の開発ボックスはElementaryOSを実行しており、Gtk2アプリケーションが実行されるたびに、警告Gtk-Message: Failed to load module "pantheon-filechooser-module"が表示されます(参照)。 物事が順調に進んだら(うまくいけば)、私もPRを取得できるかどうか見てみましょう。 しかし、間違いなくそこにあなたの入力を気に入るはずです。

これに関する更新はありますか? アトムユーザーとして、GTK2の代わりにGTK3を使用して見たいと思います。

@netsgnutはうまく機能しますか?

「%」はどういう意味ですか?

これを変更するのはこれだけですか?

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,

連絡あった ? GTK2のファイルを開くダイアログは使用するのが非常に面倒です!

@ flying-sheepああ、長いラジオの沈黙をお詫びします。 私の悪いことですが、GitHub以外の他のプロジェクトに取り組んでいます。

私たちの場合に戻ると、それは私が最初にうまくいくと思っていたものでしたが、不思議なことに私のボックスで適切なGtk3アプリケーションを構築できませんでした。 私の場合、私の当初の意図は、開発ボックス(Elementary OS Freyaを実行している)でエラーを発生させないElectronビルドを作成することです。 ただし、そのように構築しても、警告が消えることはないようです。

#4642で、 @ zcbenzは言った:

use_gtk3フラグは、Chromium側でのみ意味があります。GTK3を有効にするには、最初にlibchromiumcontentで有効にしてから、Electronでリンク設定を変更する必要があります。

では、正確に何をする必要がありますか?

  1. libchromiumcontentでGTK3の使用を有効にする: chromiumcontent.gypiにフラグを追加するだけで十分ですか? これは重要ですか、それとも電子はそのターゲットビルドを使用しませんか?
  2. Electronのリンク設定を変更します:これを行う場所は?

私はこの分野の専門家ではなく、 @ zcbenzのコメントを誤解したかどうかは

質問について:

  1. おそらくそうではありません。 libchromiumcontentは、一見すると、Atomで使用するためにアップストリームからクロムソースパッチを適用し、再パッケージ化する一連のスクリプトのようです。 あなたが言及したようにchromiumcontent.gypiのフラグを変更することは別として、少なくとも依存関係ライブラリも適切にパッケージ化されています。 libgtk2uiのインスタンスを参照してください。
  2. Electronには、libgtk2固有のUIを参照するフラグメントがあります。 それらは、クロム(および/または誘導体)内の依存性を示しています。 @zcbenzのコメントのような「リンク」は、おそらくそれらを参照しています。

Chromium

IIRCの場合、chrome / browser / ui / libgtk2ui /と一致するようにlibgtk3uiライブラリを構築し、起動時にこれら2つのライブラリを切り替える必要があります。

そして、執筆時点では、libgtk3uiはまだ存在していません:( libgtk2uiのコードもご覧ください。

私は最初にこれを投稿した後、個人のラップトップの間にいて、それ以来数ヶ月間、会社が発行したMBPを使用していました。 しかし、私はついに新しいマシンとダウンタイムを手に入れ、これを突き刺すことにしました。 これまでの私の進歩:

私はlibchromiumcontentをgtk3でビルドすることができました、それは以下を必要としました:

  • chromiumcontent.gypiに'use_gtk3': 1を追加します。
  • スクリプト/更新でinstall_sysroot()の呼び出しを手動でコメントアウトすることにより、sysrootを無効にしました。 注:libchromiumcontentバージョンによっては、設定する必要があるかもしれませんuse_sysrootchromium/src/build/common.gypiする'use_sysroot': 0 。 将来の正しいアプローチは、ビルドのクロスコンパイル機能のためにdebian_jessieに切り替えることだと思いますか?
  • 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
  • script/update -t x64 && script/build -t x64 && script/create-dist -t x64
  • 何時間も待った:)

しかし、残念ながら、ビルドが終了した後は、電子ビルドのドラッグアンドドロップだと思って少し楽観的すぎましたが、もちろんそうではありませんでした。 次のステップは、ローカルのbrightrayを構築し、sysrootではなくシステムライブラリを使用するように他のgypファイルを更新することだと思います。

そしてlibgtk2uiに関して-私はこれを読んだ場所への参照を見つけるのに問題があります(多分gentooフォーラム、クロム問題追跡システムまたはarch linuxコミュニティスレッド)-しかし、Chromiumはgtk3 / gtk2に関係なくlibgtk2uiを構築すると信じています開発者は、gtk3を使用したビルドを機能させるために最低限のことをしていました。 私は間違っている可能性があり、これがgtk2用に特別に作成されたElectronベースのパッチにどのように影響するかわかりません。

私は個人のブラウザ用に毎週chromium-gtk3ビルドを実行しますが、libgtk2uiはまだ存在しており、使用されていると想定しています。

うまくいけば、数日中にここに戻ってきて、ビルド済みのバイナリといくつかのスクリーンキャプチャを備えたPOCリポジトリにリンクします。

完了しました。まもなくatom-gtk3稼働するようになります。

screenshot from 2016-05-20 15-54-44
screenshot from 2016-05-20 15-52-32

最大のハードルは、libchromiumcontent / electronic / brightray全体で使用されているdebian_wheezy_sysrootでした。 これらのリポジトリのメンテナは、おそらくいくつかの議論を行い、jessieに切り替えるか、場合によってはsysrootをオプションにするかを決定する必要があります。

週末にかけて、ノードまたはbashスクリプトを組み合わせて、配布可能な電子gtk3実行可能ファイルを作成します。 私が行うプルリクエストは受け入れられないと思うので、今のところ、これはおそらく、仲間のgtk3ユーザーがビルドを取得して使用するための効率的な方法である必要があります。 そして、次の数週間で、AURパッケージを仲間のArchユーザーに提供しようと試みるかもしれません。

これらは、電子ビルド中のgtk3警告でしたhttps://gist.github.com/nikolowry/05865698788d66ae0edfea2eb7c7fb0c

@nikolowry sysrootを保持しながら、GTK + 3.xでsysrootにコピーする方法はありますか?

@paulcbetts WheezyがJessieにアップグレードされた場合にのみ考えます(私は間違っている可能性がありますが、gtk3をそこに忍び込もうとすると、依存関係地獄にいることになります)。 gtk3に加えて、gtk3をビルドするには次の最新のライブラリも必要です: wayland-protocols glib-2.0 gdk-3.0 gtk+-unix-print-3.0

素晴らしい@nikolowryに聞こえます、あなたの仕事に感謝します。 ソースコードはどこかにありますか? Ubuntuユーザーの生活を楽にするためにPPAを準備したいと思います。

また、この問題は最新のウィジェットを提供することだけの問題ではないことを付け加えたいと思います。 GTK2は、ボタンとツールバーのすべてのアイコンが非常に小さくレンダリングされているため、HiDPIシステムでは使用できません(少なくともubuntu 16.04では使用できません)。 幸い、Atomの場合、少なくとも私が見る限り、これはファイルを開くダイアログにのみ影響するように思われるので、Atom自体はかなり使いやすいままです。

@EiNSTeiN週末の終わりまでに、まもなくelectron-gtk3リポジトリにリンクします。

最初に少し裏話があります-これを機能させることに決めた主な理由は、Atomを毎日のドライバーとして使用していて、ファイルダイアログを見るのに我慢できなくなったためです! ただし、asar / compiled-cache / npm-not-running-post-install-scriptsの複雑さのため、そのビルドには予想よりも時間がかかりましたが、今は問題ありません。

私はこれを行うための最良の方法を検討していました-メンテナは良いリファレンスを持っているでしょう(すべての個々のリポジトリでプルリクエストを調整するのは難しいでしょう)そしてまたgtk3-would-be-usersはとして立ち上がって実行することができますすぐに不可能。

ただし、自動ビルドは行わないので、4〜6時間のビルド時間に備えるか、一部のサーバーを準備する必要があります。 これらの変更が公式レポに反映されるまで、私は時折リリースを行うことになるかもしれません。

私は、サブモジュールとして電子を使用してリポジトリを作成し、すべてのgtk3の良さを備えた電子を構築するための単一のbashスクリプトを作成することに絞り込みました。 そうすれば、すべてのディストリビューションは、これらの変更が実際に公式に行われるまで、最終的にパッケージを配布するための簡単な出発点を持つことができます。

そして、hidpiノートに- atom-gtk3私のexec cmdはGTK_THEME=Adwaita:dark GDK_SCALE=2 GDK_DPI_SCALE=.5 /usr/local/share/atom/atom --force-device-scale-factor=1.5 %Uです。 GDKスケールフラグは、 chromium-gtk3 uiフォントのサイズも修正します。 これがatom-gtk3画面です:

screenshot from 2016-05-24 02-51-28
screenshot from 2016-05-24 02-51-49

https://goo.gl/ydHspu

やあ、

ArchLinuxでGTK3を使用してElectron1.1.2をコンパイルし、 use_gtk3=1をlibchromiumcontentに渡し、brightray.gypでgtk+-2.0gtk+-3.0変更することができました

これで、キーを押すたびに、Electronのデフォルトアプリがクラッシュします。

詳細はこちら: https

ビルドスクリプトリポジトリ:
https://github.com/nikolowry/electron-gtk3

うまくいけば、週末までにそれをまとめるでしょう。 これはWIPであり、まだ意味のあるものを構築していません。

@EiNSTeiN@ tensor5 - https://github.com/nikolowry/electron-gtk3がビルドされているはずです。 debugrelease両方をビルドするように特に指示しない限り、 releaseバージョンのみをビルドすることに注意してください。 READMEを確認し、問題が発生した場合は問題を開いてください。

@zcbenz

編集: @ tensor5はXまたはWaylandを使用していますか? クロムgtk3ビルドがWaylandの主要な入力イベントでクラッシュしていることを私は知っています。

@nikolowry :はい、私はWaylandを使用していましたが、Xでも問題なく動作します。ありがとうございます。 このクロムの問題がどこかで議論されているかどうか知っていますか?

これが見つかりました: https

@nikolowry Chromiumの構築構成に従っていますが、Linuxディストリビューションがたくさんあり、すべてをテストすることはできませんが、Chromiumはどこでも完全にテストされているため、Chromiumに従うのは安全です。

GTK + 3用にビルドするフラグを追加するのは良いことです。また、ビルドスクリプトへのリンクを追加するのも良いことです。 これは、Linuxビルド命令の高度なトピックの一部に

@zcbenzは良さそうです-sysrootにWheezyの代わりにJessieを使用する実行可能なPythonスクリプトがありますが、アップストリームChromiumでデフォルトとして設定されるのを待つのが最善だと思います。

一般に、glibc ++のバージョン管理のため、ソフトウェアの配布に関しては、見つけることができる最も古いディストリビューションに対して構築することは良いことです-Jessieへのアップグレードは、Electronを使用していた孤児の人々を(一般的にははるかに安全だと思いますが)過去。 この問題はRHELユーザーに多く見られます

@ tensor5はWaylandで起動する方法を考え出しました。 そのChromiumチケットにコメントし、gtk3リポジトリを更新しました。

ChromiumはXWaylandモジュールに自動的にフックしないため、 GDK_BACKEND=x11 electronを実行する必要があります。

@nikolowry素晴らしい

したがって、私が正しく理解していれば、問題は、GTK3が電子を純粋なWaylandアプリケーションであると見なしているのに対し、そうではないということです。

@ tensor5正確に! GTK3は、ツールキットを使用するすべてのアプリがWaylandに対応していることを前提としています(したがって、必要に応じてXWaylandをロードする責任があります)。

私は今週末、Chromiumのソースコードを深く掘り下げて理解する準備をしていました。ログを生成しようとしていたときに、 https: //fedoraproject.org/wiki/How_to_debug_Wayland_problemsから簡単な解決策に出くわしました

ChromiumとAtomは、Waylandに対応していない最後のアプリでした。混合dpiモードでマルチモニターに接続しても、Skylakeラップトップがxrandr経由でクラッシュすることはもうありません!!!!


編集:いくつかのAURパッケージも維持しているので、デスクトップファイルを編集して「envGDK_BACKEND = x11」を含めることをお勧めします。これにより、アプリをXとWaylandの両方で実行できるようになり、他のすべての人の頭痛の種を減らすことができます。未来!

@nikolowry私はすでにそれに

最終的には、これは電子源で修正する必要があります。ランチャースクリプトを使用するのは最も洗練された方法ではありません。

ところで、AURパッケージは私のものではありません。 私はリポジトリを維持してい

@nikolowry FirefoxもXwaylandに依存するGTK3アプリケーションですが、正常に動作します。 そこで私はそれを調べました。ここでわかるように、最初にX11バックエンドを試し、次に検出されたdisplay_namegdk_display_openます。

おそらく、Chromiumでも同様のことができます。

エレメンタリーOSでは、pantheon-file-chooserを使用するためにGTK3が必要です。そうでない場合は、次のようになります。

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

Qt5-WebEngineをサポート/移植しないのはなぜですか? とにかくクロムのエンジンを使用しており、Qtではgtkとは異なりすべてがはるかにネイティブに見えます...

さらに、qt5は、gnome開発以外のことを気にしないという理由だけで、F ** kingAPIを毎回変更するgtk3のように常に壊れているわけではありません。

これは、 gtkが悪く、qtが優れている理由(2年前ですが、それでも良好で関連性があります)の

Qt 5.6.xがLTSになり、ライセンスが5.7

個人的には、そのために設計されていないのに、なぜ人々がgnome以外でgtkを使用しているのかわかりません。

@ahjolinna実際、GTK +は、Gnome以外のアプリケーション開発にも使用することを目的としています。 いずれにせよ、APIをQTに変更することは、Chromiumアップストリームから多くのパッチを適用する必要があるため、Electronチームにとって悪夢になります。 それはトラブルの価値がありません。

GTK + 3は本質的にGNOMEと結婚しています。なぜなら、基本的に(?)すべてのGTK開発者はGNOME開発者であり、RedHatに採用されているからです。

前述のGTKAPIの破損は、RedHatがGNOMEの前進を優先するために発生します。 @ahjolinnaは、Qt5がより安定していることは正しいですが、クロムインスタンスへのアクセスは制限されています。

その理由は安定性でもあります。クロム自体が十分に壊れているため、一部の領域で安定したAPIを維持するためにリソースをコミットすることしかできません。

@nikolowry https://github.com/nikolowry/electron-gtk3を使用してgtk3をサポートする電子をビルドする場合、atom-gtk3をビルドするためにatomビルドで何を変更する必要がありますか?

gtk3ビルドを使用している場合、ライトテーマを使用すると、メニューバーに白いテキストが表示される可能性があります。 このパッチは問題を解決します。

screenshot from 2016-07-20 10-21-21

screenshot from 2016-07-20 10-21-55

数日中に他のgtk3ビルド警告を修正する予定です。

Chromium with Gtk2のメニューは「ネイティブgtkスタイル」ではなく、非常に醜いです。 Gtk3ビルドはこれを修正しますか?

@メンチ。 いいえ、gtk3のメニューバーはgtk2とまったく同じように見えます。 あなたは正しいです、それは完全にネイティブではありません、単にテキストと背景の色はgtkテーマに従います。
過去数日間のコードを調べて、修正できるかどうかを確認しました。 1つの問題は、ネイティブgtkコードがクロスプラットフォームラッパーのレイヤーの背後に隠れていることです。 たぶん、そこにいるgtkの専門家がこれを手伝ってくれるでしょう。

@ tensor5メニューはクロスプラットフォームラッパーに実装する必要があると思います。 OS Xのメニューがネイティブであり、ネイティブのCocoaコードもクロスプラットフォームラッパーのレイヤーの背後に隠されているように。

@Menciもちろん、そのようなパッチを受け入れることができる唯一の方法です。

Gnomeアプリメニューがあると便利です。

LibreOfficeがどのようにそれを行ったかを見ることができます、それは同様の方法です。

LibreOfficeのメニューは実際にはネイティブではないと思います。 ドロップシャドウやアニメーションの表示/非表示はありません。

GTK +アプリはgnome(および他のgtkスピンオフ)の外でネイティブに見えたことはなく、KDE、LXQtでは常にひどいように見えました)そしてUnity 8が到着したときに同じ問題が発生します(Qt5ベース)。 KDEチームはこの問題でgtkチームと協力しようとしましたが、彼らは100%嫌いな人であり、APIが変更されたり壊れたりすることを気にせず、breeze-gtkテーマのような(いくつかの)KDEのものを壊します、ところで。 gtkチームの愚かな推論のためにハードコーディングする必要がありました。*

ところで。 KDE、LXQt、Unity 8 + Ubuntu TouchとSailfishOSを使用すると、Qt5の「マーケットシェア」はgtkよりもはるかに大きくなり、少なくとも長期的には大きな影響があります。

PS。 libreofficeについては、GTKなしでビルドし、ネイティブfilepickerを使用して作成できます。これは、たとえばChakraOSが行うこと、 PKGBUILD 、なぜですか? GTKの使用をできるだけ避けたいKDE / Qtに焦点を当てたディストリビューションだからです


編集

* GTK開発者は、以前はKDEでのGTK統合に使用されていたテーマエンジンへのアクセスをブロックしたため、現在は「CSSの方法」を試すしか方法がありません。


Qtを使用する私が知っているいくつかのアプリ:
Dropbox、OBS、MEGA、VIber、Wireshark、makemkv、yacreader、masterpdfeditor、vapoursynth-editor、SVP、teamspeak3、mkvtoolnix-gui、hplip、scribus WPS-office ..

Qt5を使用する他のDE: http ://papyros.io/およびhttps://lumina-desktop.org/

@ahjolinnaあなたは間違った群衆を説得しようとしていると思います。 Chromiumが切り替えを行わない場合、Electronが切り替えを行うのではないかと私は強く疑っています。 ElectronチームにこのプロジェクトとChromiumのQT5フォークを維持するように依頼することはあまりにも多くを求めています。

さらに、この問題はGTK2をGTK3に置き換えることに関するものです。 彼らに切り替えを検討してもらいたい場合は、新しい問題を作成してください。 それ以外の場合はトピックから外れ、このスレッドがノイズでいっぱいになります。

@alzadudeいくつかのgruntビルドスクリプトを編集して、ビルド済みの電子をダウンロードしないようにする必要があります。package.jsonバージョンを編集して、gtk3でローカルに行った電子ビルドと一致させます。今のメモリ)。 難しいことではありませんが、前のビルドで行ったいくつかの手順を常に忘れているように見えるため、新しいビルドを実行するときは常に1分かかります。

@ tensor5が彼のarch-atomリポジトリでgtk3を使用し始めている場合は、それを試してみることをお勧めします-そうでない場合は、次にビルドを実行して変更を文書化するときにここに戻ります(通常は週末)

@nikolowryありがとう、いくつかの文書化された変更は素晴らしいでしょう:)

私はFedoraを使用しているので、このFedoracoprに基づいた変更を組み込むことを検討しています。

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

このCoprは現在、Fedoraの標準パッケージに最も近いもののようです。 これは、次のアップストリームrpm仕様ファイルに基づいています。

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

そして、このBugzillaバグで言及されています:

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

既存の作業に基づいて、ElectronとAtomのgtk3ビルド用に独自のCoprを作成することを検討します(文書化された変更に基づいて、必要なパッチを組み込むためにアップストリームrpmスペックファイルをフォークします)。 もちろん、他の誰かが私を殴らない限り:)

私はこれのためにgentooebuildを書き込もうとしていますが、成功していません。 誰かが私にこれをするのを手伝ってくれたら、私はとても感謝しています。

@ eternal-sorrow現在公式のGentooツリーにあるebuildであるdev-util / electronicをすでに見ましたか?

@devurandom 、やった。 これは非常に古いバージョンの電子(0.36.12)です。 現在のバージョン(1.3.1)用に変更し、すべてのパッチを適用しましたが、v8リンクの問題(多くの未定義のv8シンボル)が発生します。

@ eternal-悲しみ

  1. そのパッケージのメンテナである[email protected]に連絡して
  2. ここGHでebuildを使用してオーバーレイリポジトリをセットアップします。一緒に解決できるかもしれません。

@ eternal-Arch Linuxの悲しみは、GTK3を使用してElectronの最新バージョン

これについて何か進展はありますか?

@ nikolowry 、atom-gtk3で使用している原子と電子のバージョンはどれですか? 現在のバージョンのアトムにはelectron-0.37が必要であり、現在のバージョンの電子では実行できないことに気付きました。 私が間違っている?

@ eternal-sorrow Atomは最近、Electronの新しいバージョンに更新されました。

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

gtk3を使用する方法はありますか? 特にファイルダイアログを改善するためにそれを気に入っていただければ幸いです。

archlinuxにはすでにgtk3ビルドがあるので、これが電子コアであるために欠けているものは何ですか?

彼らは切り替えが上流で行われることを望んでいると思います。 そして、現在正式に計画されています。https://chromium.googlesource.com/chromium/src/+/acc4214c4dece4e70fb53355d557bd45f35965d6/docs/linux_gtk_theme_integration.md#GTK3を参照して

追加情報、クロム/グーグルクローム開発チャンネルはgtk 3を使用しているので、今は時間の問題です。

https://bugs.chromium.org/p/chromium/issues/detail?id=79722#c110でChrome59について確認されてい

Chrome 59がリリースされました! :多田:

Chrome 59がリリースされたので、Linux用のGTK3で構築されたElectronプレリリースを見るのは素晴らしいことです。

GTK3のサポートはChromium安定版(59)になりました。つまり、Electronでまもなく

いくつかの質問を聞きたいんです:

  • なぜGTK3サポートが必要なのですか?
  • このスレッドでよく言及されている「ファイルダイアログ」が表示されます。 GTK2では何が問題でしたか?GTK3ではどのように改善されていますか?
  • このアップデートにより、パフォーマンスや互換性などが改善されますか? それともUIだけですか?
  • 人々は他にどのような改善を期待できますか?
  • どのLinuxディストリビューションがGTK(3)を使用していますか?

@zeke

なぜGTK3サポートが必要なのですか? このスレッドでよく言及されている「ファイルダイアログ」が表示されます。

私が興味を持っている改善点の1つは、 Flatpakサンドボックス内で実行されているElectronアプリケーションが、ホスト上のファイルチューザーへのポータルをシームレスに使用するようになることです。 ユーザーがQtポータルをインストールしている場合、これは正しいQtのものを使用することさえあります。

このアップデートにより、パフォーマンスや互換性などが改善されますか? それともUIだけですか?

理論的には、Gtk3のhidpiサポートが関連している可能性がありますが、これがChromiumのレンダリングとどのように相互作用し、そのほとんどをバイパスするのかわかりません。 したがって、おそらくテーマを変更するだけです。

どのLinuxディストリビューションがGTK(3)を使用していますか?

事実上、すべてのディストリビューションにはGtk3があります。 Unity、GNOME、MATE、Cinnamon、Budgie、そして最終的にはXFCEは、アプリケーションのメインツールキットとしてGtk3を使用します。

@zeke

どのLinuxディストリビューションがGTK(3)を使用していますか?

すべての主要なLinuxディストリビューションは、デスクトップ(シェル)にGTK3を使用しています。 KDEフレーバーを持つものもありますが、それらすべてのデフォルトはGTK3です。

このスレッドでよく言及されている「ファイルダイアログ」が表示されます。 GTK2では何が問題でしたか?GTK3ではどのように改善されていますか?

はい、GTK2とGTK3アプリケーションは同じシステムに共存できますが、GTK3アプリケーションは現在のデスクトップとより適切に統合されています。 [ファイルの選択]ダイアログは1つの良い例です。

@zeke

なぜGTK3サポートが必要なのですか?

私は一貫性を重視しています–ファイルダイアログはGTK 3でかなり異なり、テーマはGTKバージョン間でわずかに一貫性がないことがよくあります。 また、システムを最小限に抑えるのも好きです。AtomがGTK 2を削除するということは、GTK2をインストールする理由が1つ少なくなることを意味します。

このスレッドでよく言及されている「ファイルダイアログ」が表示されます。 GTK2では何が問題でしたか?GTK3ではどのように改善されていますか?

上記のように、私にとって最も重要なことは一貫性です。 GTK 3ダイアログは、ディレクトリ内の増分検索の代わりに再帰的な名前検索を使用するため、実際には劣っていると見なされる人もいます。

人々は他にどのような改善を期待できますか?

メニューは、ニーモニックをサポートしていないように見えるカスタム実装や矢印キーを使用した隣接するメニュー間のジャンプではなく、GTKも使用する必要があります。

GTK 2をアトムドロップすると、GTK2をインストールする理由が1つ少なくなります。

@jtojnar :デフォルトでGTK3を使用する新しいバージョンのLinuxを使用している場合、GTK3に更新されていないアプリをサポートするには、GTK2を手動でインストールする必要がありますか? Atom(および他のすべてのElectronアプリ)の他に、この問題を抱えている他の人気のあるアプリは何ですか?

@zeke依存関係のインストールは通常、ディストリビューションのパッケージマネージャーによって自動的に行われますlibgtk3もダウンロードされ、GTK 2アプリをインストールするとlibgtk2が取得されます。 両方を安全にインストールできます。SSDの容量が少ないので、できる限りすべてのレガシーパッケージを削除したいと思います。

なぜGTK3サポートが必要なのですか?

GTK3はより新しく、HiDPIをサポートしています。
GTK2はもう開発されておらず、現代的でもありません。

このスレッドでよく言及されている「ファイルダイアログ」が表示されます。 GTK2では何が問題でしたか?GTK3ではどのように改善されていますか?

これについては知らない。

このアップデートにより、パフォーマンスや互換性などが改善されますか? それともUIだけですか?

GTK3はいくつかのCPUとRAMの機能をよりよく利用すると言われていますが、そうでないかどうかはわかりません。 しかし、それは大きなUIアップデートになるでしょう。

人々は他にどのような改善を期待できますか?

より良いテーマのサポート。

どのLinuxディストリビューションがGTK(3)を使用していますか?

すべてのディストリビューションのリポジトリにはGTK3があります。
Gnome 3、Budgie、Deepin、MATE、soon(tm)XFCEなど、多くの主要なデスクトップ環境でGTK3が使用されています。

このための前提条件は、#9946のプルリクエストがあるChromium59です。

@zeke主な

このスレッドでよく言及されている「ファイルダイアログ」が表示されます。 GTK2では何が問題でしたか?GTK3ではどのように改善されていますか?

GTK3と比較したGTK2は、UIの外観が異なる(ファイルブラウザなどのレイアウト/機能の違い)WindowsまたはmacOSの以前のバージョンとして最もよく説明される可能性があります。 Windows 10を実行していて、Windows VistaまたはXPのようなファイルダイアログが表示されると、見た目がおかしくなり、特定の機能やUXが不足している可能性があります。

KDEのようなデスクトップ環境(DE)では、これにより、そのDEのより一般的なツールキットであるQtではなく、GTK3ダイアログが作成されます。 そのため、そこにはまだいくつかの矛盾がありますが、GTK2よりも優れています。

デフォルトのBreezeテーマを使用したKDEの例を次に示します。

現在のElectronアプリとのGTK2ダイアログ-GitKraken:
GTK2 Dialog with current Electron apps - GitKraken

GTK3ダイアログ-メルド:
GTK3 Dialog - Meld

Qtダイアログ-ケイト:
Qt Dialog - Kate

Mono / .NET(?)ダイアログ-BundleModder-Linuxでは一般的ではありませんが、Javaアプリケーションでも一般的でないツールキットを使用できます。
Mono(?) Dialog - BundleModder - Uncommon on Linux, Java applications can also use an uncommon toolkit.

ご覧のとおり、スタイルの一貫性はUIツールキットによって大きく異なります。 それはカジュアルユーザーとしてなぜそれらが異なるのか混乱する可能性があり、それらが同じ目的であるのか、ナビゲーション/プレゼンテーションの詳細がそれらの間で異なることに不満を感じているのか疑問に思います(GTKはダブルクリックするかもしれませんが、Qtはシングル用に設定されているかもしれませんフォルダーナビゲーションをクリックします)、または一貫性の欠如を専門家ではないと見なします。

Gnome(GTKに焦点を当てたDE)は、GTK3とQtの間の一貫性を保ちながら、KDE(Qtに焦点を当てたDE)よりもこれをうまく処理できます。これは、Qtのツールキットがプラットフォーム間で統合され、ネイティブな感覚/エクスペリエンスを提供するように設計されているためです。 GTK開発者は、DEの問題に対処するためのコードを提供したいと考えているにもかかわらず、Gnome以外のDEでツールキットをサポートすることには消極的です。 ユーザーがGTK2または一般的でないツールキットを使用する古いアプリケーションを使用していない場合は、より良いエクスペリエンスが得られます。

ツールキットが他のツールキットと同等のアプリほど強力ではない場合、GTKアプリとQtアプリが混在していることがよくあります。一部のユーザーにとっては、単一のツールキットアプリを使用するだけで実行可能です(KaOSはQt5に対応するディストリビューションです)。 ChromeなどのオプションのGTKアプリが利用可能です)。 Electronアプリケーションの人気により、GTKを回避することが常に望ましいとは限りません。

なぜGTK3サポートが必要なのですか?

一貫性、ファイルダイアログはKDEユーザーとして私に最も目立つものです。

このアップデートにより、パフォーマンスや互換性などが改善されますか? それともUIだけですか?
人々は他にどのような改善を期待できますか?

FlatPak(サンドボックス化されたディストリビューションに依存しないアプリ、GUIアプリのDocker /コンテナーのようなもの)についてはよくわかりませんが、DEとの統合を含め、GTK3の方がGTK2よりも優れていると思います(FlatPakのテーマは別です)一貫性のためのストーリー、FlatPakのGTK3は最近テーマのサポートを取得しました。他のツールキットもこれを追加する必要があります)。 前述のFlatPakは、ポータルのサポートを介してファイルダイアログの問題を軽減することもできます。

個人的にはGTK2とGTK3の違いについてはあまり知りませんが、私が想像するGTK3の方がHiDPIの話の方が良いでしょう(GTK2はそうならないかもしれません)。 テーマのサポートの方が優れていると思います。少なくとも、特に将来的には、GTK3のテーマを2よりも取得する可能性が高くなります。 Gnomeでは、ファイルダイアログがクライアントサイドデコレーション(CSD)によって少し異なる場合があり、これらのユーザーのUXが向上します。 KDEでは、GTK3のサポートはグローバルメニュー機能でうまく機能するかもしれないと思います(それでもWIP、アプリケーションウィンドウに縛られる代わりにメニューバーのようなmacOS)。

どのLinuxディストリビューションがGTK(3)を使用していますか?

現代のディストリビューションの大部分は、GTK3を使用しているか、私が知る限りそれをサポートしています。 GTK2はかなり古いです。 ChromeまたはElectronアプリを使用している場合は、GTKを使用しています(おそらく2/3の組み合わせですが、3に傾いています)。

@ polarathene 、GTK3サポートが将来Waylandサポートを追加できることについては言及していませんが、GTK2では追加できません。

JFYI Chromium GTK2ビルドは、最新の安定版60.0.3112.90およびベータ版61.0.3163.31で壊れています。
ただし、最新のマスターで動作します。

そしてところで、それはもはや公式に維持されていません。
https://groups.google.com/a/chromium.org/d/msg/chromium-dev/iO3qzex6oYA/Q-i4Cie3BwAJ

皆さん、GTK3の長所に関する素晴らしいフィードバック。 ご意見ありがとうございます。

残念ながら、GTK3アップデートはChrome59を搭載したElectron1.8に到達しないようです。現在ビルドをブロックしているため、GTK3がサポートされる前に、次のChromiumが61にバンプするまで待つ必要があります(60をスキップします)。電子で。

それは正しいですか、@ alexeykuzmin?

@zekeクロム61の隆起がいつ起こるかについての大まかな見積もりはありますか? そのリリースに合わせて、ネイティブES6Webコンポーネントへの移行を計画したいと思います。 歴史的に、バンプはリリース後1か月ほどで発生しますか?

@zeke
はい、Chromium59ブランチのGTK3で問題が発生しました。
ただし、今後のChromium 61アップグレードでは、GTK2からGTK3に切り替える必要があります。

@cpoole現在、Chromium 61がElectronに着陸する時期の見積もりはありませんが、現在https://github.com/electron/libchromiumcontent/pull/335で作業中@ tonyganch@ cifratila@ alexeykuzmin@ alespergl 、その他?)がそのプロセスを支援しており、GitHubのElectronチームがCIの改善とElectronリリースプロセスのスムーズ化に集中できるようになっています。 だから私は楽観的です:)

なぜGTK3サポートが必要なのですか?

deepinscreenshot_select-area_20170830114704

@deikatsuoそれは何のブラウザですか? クロームとエピファニーに赤ちゃんがいたようです...

@mdsittonエピファニー👍

これに関するニュースはありますか?

@ ziggy42最新のクロム61(https://github.com/electron/electron/pull/10213)にはすでに存在しているはずです。 マスターにマージして、ある時点でリリースするだけの問題だと思います。

待ちきれません、それらの醜いファイルピッカーは私の目を燃やします:fire:

この変更により、ElectronアプリでCSSが許可されますか?

それで、クロム61は統合されます、gtk3はそれに付属しますか?

Electronは現在マスターブランチでGTK3を使用しており、次のマイナー/メジャーリリースで出荷されます。

@ahjolinna

あなたがこの議論にいくらかの正気を費やしてくれてありがとう。

すでに述べたKaOSに本当に興味があるかもしれません。
それは、チャクラを数年間素晴らしいものにしたまさにその人、私見によって維持されています。

@全て

GTK + 3はいつリリースされましたか?

7年前。

それをしばらく口の中で溶かしてください。

そして、膨大な数のソフトウェアプロジェクトがまだ2にあります。
移植は楽しみですので..

XFCE、Mate、その他多数の人々がコードを移植するのに6年かかりました。
他のプロジェクトは、2年以内にGTKからQtに完全に切り替わりました。

そしてそうです:GTK +はGNOMEによって開発されており、リポジトリもそこにあります。
それは、本質的に、そして定義上、GNOMEのために開発されたものであり、他には何もありません。

Qtは、いくつかのプラットフォームへの真のネイティブ統合のために開発されました。

電子は何ですか?

GNOMEショップ?

良いですね。

賢い思考。

これは、命令型プログラミングや関数型プログラミング、およびこのシーンの他の多くの側面と同じです。冗長で古くて時代遅れのソフトウェアは、中毒性のある薬物として扱われることが多く、1つになります。

そして、新しくて賢い革新的なソフトウェアは、誤解と純粋な無知によって扱われます。

10、12のプロジェクトがGTK +からQtに切り替わりましたが、その逆が起こった1つのケースはわかりません。

これをもう一度あなたの舌に溶かしてみましょう:それは彼らの統合されたUIコード全体の完全な書き直しを意味します。
多くの場合、深くネストされています。

つまり、既存のツールのメジャーアップグレードと比較して、それを好むということです。
そして、今日まで、彼ら全員がその決定に満足しています。

彼らに聞いてください。

あなたが代替案を考慮せずに群れに従う前に。

@ahjolinnaは、これらの人物の1人のビデオを投稿しました

GTKはChromiumでAuraへのバインディングとして使用されており、これはLinux / freeBSD / Solarisなどでのみ使用されます。
WindowsとmacOSのビルドにはそれがありません。

:ウィンク:

@ShalokShalomでポイントを獲得し。ElectronはChromiumチームが提供するものに従います。

フォークボタンは上部にありますので、お気軽に。

ええ、これは不必要に研磨性がありました。

しかし、私は同意します。 GTKには、痛みを引き起こす不必要な破損が多すぎるため、Qtの方が適しています。

  • IF QtWebEngineは、基礎となるクロムインスタンスへの十分なアクセスを提供します
  • IF QtWebEngineは十分にすぐに最新のクロムを追跡します

議論をより適切な場所に移すことをお勧めします。 @ShalokShalom 、ここで新しい問題を開いて、今よりももっと

VLC 、Wireshark、LXQt、その他の注目すべきソフトウェアプロジェクトも、以前はGTKに基づいていました。

それは真実ではありません。 VLCはGTKではなくQtの前にwxWidgetsを使用していました: https

GTKの人々は、3.xシリーズでは破損やバージョン管理について十分に伝達しておらず、 https:/で読むことができるように、より良く、より明確な長期安定性を備えて、将来さらに努力することをかなり前から認めているよう

また、QtとGTKは、歴史、裏付け、目標が異なるため、1対1で公平に比較​​することはできません。私の意見では、どちらもあなたの視点に応じて長所と短所があります。

GTKはGNOMEプロジェクトのためだけに作られていると述べることも、私の意見では不公平な包括的な声明です。

ハ! 私は本当にそれらの計画について知りませんでした。 彼らはついに学んだようだ。 彼らがCSSの重大な変更を本当の重大な変更と見なし始めることを期待しましょう。

私が最後に聞いたのは…うーん…エキセントリックなGTK4.0はGTK4ではないということでした。 だから、ついにsemverとほぼ同じくらい良いものに到達しました! 彼らは20年前のQtとほぼ同じくらいうまくやっています! 😁

このツイッターの投稿に基づいて、すぐにデフォルトでネイティブGTK3をサポートするElectronが表示されるはずです。

Electron 2.0.0-beta.1には、更新されたChromiumとNode.js、macOSのアプリ内購入、 Linux用のGTK3サポートなどが含まれています。

はい。 このための実際の作業はChromiumの作成者によって行われ、ElectronはElectron2.0.0でのChromiumのアップグレードを通じてそれを取得しました。

さらに、Electron自身のコードはhttps://github.com/electron/electron/pull/11879でGTK3化されました

ええ、これは不必要に研磨性がありました。
しかし、私は同意します。 GTKには不必要な破損が多すぎて痛みを引き起こします、Qt
より良い選択だっただろう
QtWebEngineが基盤となるクロムインスタンスへの十分なアクセスを提供する場合
QtWebEngineが最新のChromiumを十分迅速に追跡する場合

さて、これが主な問題です。 人々は、自分たちのために実装するのが最も速いものを考えますが、それは問題ありませんが、それを実行するための実際の実装は、長期的な保守とは非常に異なるものであることを忘れがちです。

私の観点からは、言及された問題に取り組むことができることは非常に明確です。

GTK3ポートで実際に作業するコーダーの数と、UIコード全体を新しいツールキットに移植するコーダーの数を比較すると、その違いがどれほど素晴らしいかがわかります。 「GTKからQtへ:奇妙な旅」というビデオをすでに投稿したと思います。

Qtのサポートをハッキングするのではなく、すぐに使用できるように見えるという理由だけで、古いソフトウェアに焦点を当てるのはなぜですか?

その「私は準備ができていると思われるものを使用します」という教義は、長期的な決定を完全に無視します。 はい、そもそももう少し手間がかかるように見えるかもしれませんが、実装された最新のツールキットは確かにメリットがあります。

また、QtWebEngineがChromeにそれほど迅速に従わないことも、それほど劇的ではありません。
十分に高速で、Qupzillaは、特にKaOSなどの適切な環境で、驚くべきことを実行できることを証明しています。

Qupzillaや他のソフトウェアが単一のコーダーによって維持される素晴らしいソフトウェアを出荷することが証明されているので、「基盤となるChromiumへのアクセスを増やす」必要があり、「QtWebEngineはChromiumに十分な速さで従わない」と本当に思いますか?

Electronの本格的なWebブラウザとして、より多くのアクセスとより迅速なフォローが必要だと思いますか? どうして?

今、あなたは非常に多くのプロジェクトでこの不器用なソフトウェアスタックに座っており、小さなチームは深くネストされたコードの40〜60%をQtに迅速かつ効率的に移植することができます。

GTK2からGTK3まで、彼らがなんとかできなかったことは、非常に素晴らしいことです。 述べたように:ほとんどのプロジェクトはメジャーバージョン

そして、ほとんど誰もがそれを無視しているようですか? とても悲しいので、最初は科学界で、原始的な決定が広がり続けています。

平和 :)

@ShalokShalom 、「古いソフトウェア」とはどういう意味ですか? GTK +? あなたがそれを言う理由は何ですか?

このQtスパムで止めてください。これはGTK3ポートに関する問題です。 メンテナにQtに切り替えるよう説得する必要があると感じた場合は、別の問題を開いてください。 Qtファンからのメッセージではなく、実装の進捗状況に関するニュースを受け取りたいです。

過度のトピック外の議論のためにこの会話をロックします。

ロックは症状に対処するだけですが、GTK3への移行が終わり、GTK2からGTK3への移行というこの問題のトピックについて議論する余地があまりないため、合理的な迅速な修正です。

このページは役に立ちましたか?
0 / 5 - 0 評価