Electron: Linux 빌드에서 GTK2 w GTK3 교체 고려

Chrome 47로 업그레이드한 후 기분이 좋습니다.

Chrome 47은 3일 전에 출시되었습니다. :) http://googlechromereleases.blogspot.se/2015/12/stable-channel-update.html

조금 파고 들었지만 여전히 use_gtk3 플래그를 어디에 둘지 잘 모르겠습니다. @zcbenz 하시겠습니까?

@zcbenz 또는 어디에 넣어야 하는지 알려주실 수 있나요?

저는 Chromium용 빌드 시스템 뒤에 있는 빌드 동작에 대한 전문가는 아니지만 Chromium 관련 버그를 읽고 variables to common.gypi 좋습니다. 관련 라인은 여기에 있습니다 .

사실 나는 그것을 위해 Linux 상자에서도 테스트하고 있습니다. 내 현재 개발 상자는 Elementary OS를 실행하고 Gtk2 애플리케이션이 실행될 때마다 경고 Gtk-Message: Failed to load module "pantheon-filechooser-module" ( Ref )를 표시합니다. 일이 순조롭게 진행되면 (잘하면) 나도 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에서 사용하기 위해 upstream , patch 및 repackage 에서 크롬 소스 를 종속성 라이브러리도 적절하게 패키지됩니다 . libgtk2ui 의 인스턴스를 참조하십시오.
2. Electron 에는 @zcbenz 의 의견에서와 같이 "링크"는 아마도 그것들을 참조할 것입니다.

Chromium 의

IIRC에서는 chrome/browser/ui/libgtk2ui/와 일치하도록 libgtk3ui 라이브러리를 빌드해야 하며 시작 시 이 두 라이브러리를 전환해야 합니다.

그리고 글을 쓰는 시점에서 libgtk3ui는 아직 존재하지 않습니다 :( libgtk2ui의 코드도 볼 수 있습니다.

나는 원래 이것을 게시한 후 개인 노트북 사이에 있었고 그 이후로 몇 달 동안 회사에서 발행한 MBP를 사용하고 있었습니다. 그러나 마침내 내 새 기계, 가동 중지 시간이 생겼고 이것으로 찔러보기로 결정했습니다. 지금까지 나의 진행 상황:

gtk3로 빌드할 libchromiumcontent를 얻을 수 있었고 다음이 수반되었습니다.

• chromiumcontent.gypi에 'use_gtk3': 1 를 추가합니다.
• 스크립트/업데이트에서 install_sysroot() 에 대한 호출을 수동으로 주석 처리하여 sysroot를 비활성화했습니다. 참고: libchromiumcontent 버전에 따라 use_sysroot 의 chromium/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와 관련하여 - 나는 이것을 읽은 곳(젠투 포럼, 크롬 이슈 트래커 또는 아치 리눅스 커뮤니티 스레드)에 대한 참조를 찾는 데 어려움을 겪고 있습니다. 개발자들은 gtk3를 사용하여 빌드를 작동시키기 위해 최소한의 작업을 수행했습니다. 내가 틀릴 수 있고 이것이 gtk2용으로 특별히 작성된 Electron 기반 패치에 어떤 영향을 미칠지 모르겠습니다.

개인 브라우저를 위해 매주 chromium-gtk3 빌드를 수행하고 libgtk2ui가 여전히 존재하며 사용한다고 가정합니다.

나는 앞으로 며칠 안에 여기로 돌아와 미리 빌드된 바이너리와 일부 화면 캡처가 있는 내 POC 저장소에 연결할 것입니다.

완료하고 곧 atom-gtk3 수 있습니다.

가장 큰 장애물은 debian_wheezy_sysroot가 libchromiumcontent/electron/brightray 전체에서 사용되고 있다는 것입니다. 해당 리포지토리의 유지 관리자는 jessie로 전환할지 아니면 sysroot를 선택 사항으로 만들지 여부를 논의하고 결정을 내려야 할 것입니다.

주말 동안 나는 배포 가능한 전자 gtk3 실행 파일을 빌드하기 위해 노드 또는 bash 스크립트를 조합하려고 노력할 것입니다. 내가 하는 어떤 풀 리퀘스트도 받아들여질 것이라고 생각하지 않는다. 그래서 지금으로서는 이것이 아마도 동료 gtk3 사용자들이 빌드를 얻고 사용하는 가장 효율적인 방법이 될 것이다. 그리고 다음 몇 주 동안 동료 Arch 사용자를 위해 일부 AUR 패키지를 제공하려고 시도할 수도 있습니다.

이들은 전자 빌드시 gtk3 경고했다 https://gist.github.com/nikolowry/05865698788d66ae0edfea2eb7c7fb0c

@nikolowry sysroot를 유지하면서 GTK+ 3.x에서 sysroot로 복사할 수 있는 방법이 있습니까?

@paulcbetts Wheezy가 Jessie로 업그레이드된 경우에만 생각합니다. gtk3 외에도 gtk3를 빌드하려면 다음과 같은 최신 라이브러리가 필요합니다. wayland-protocols glib-2.0 gdk-3.0 gtk+-unix-print-3.0 .

멋진 @nikolowry로 들립니다 . 작업해 주셔서 감사합니다. 소스 코드가 어딘가에 있습니까? 우분투 사용자의 삶을 더 쉽게 만들기 위해 PPA를 준비하고 싶습니다.

나는 또한 이 문제가 현대적인 위젯을 제공하는 문제가 아니라는 점을 덧붙이고 싶습니다. GTK2는 버튼과 도구 모음의 모든 아이콘이 매우 작게 렌더링되기 때문에 HiDPI 시스템(적어도 우분투 16.04에서는 사용 불가)에서 사용할 수 없습니다. 다행스럽게도 Atom의 경우 이것은 적어도 내가 볼 수 있는 한 파일 열기 대화 상자에만 영향을 미치므로 Atom 자체는 여전히 상당히 유용합니다.

@EiNSTeiN 주말이 끝날 때까지 electron-gtk3 repo에 곧 다시 연결하겠습니다.

약간의 뒷이야기 먼저 - 내가 이 작업을 하기로 결정한 주된 이유는 Atom을 일상적인 드라이버로 사용하고 더 이상 파일 대화 상자를 볼 수 없었기 때문입니다! 그러나 그 빌드는 asar/compiled-cache/npm-not-running-post-install-scripts의 복잡성으로 인해 예상보다 오래 걸렸지만 이제 가도 됩니다.

나는 이것을 하는 가장 좋은 방법에 대해 곰곰이 생각하고 있었다 - 그래서 유지 관리자는 좋은 참조를 가질 것이고(모든 개별 리포지토리에서 풀 리퀘스트를 조정하는 것은 힘들 것이다) 또한 gtk3-would-be-users는 다음과 같이 시작하여 실행할 수 있습니다. 빨리 불가능.

그러나 나는 자동화된 빌드를 하지 않을 것이므로 모두가 4-6시간의 빌드 시간을 준비하거나 일부 서버를 준비해야 합니다. 이러한 변경 사항이 공식 리포지토리에 반영될 때까지 가끔 릴리스를 수행하게 될 수도 있습니다.

나는 전자를 하위 모듈로 사용하여 repo를 만들고 모든 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 의 일부 화면입니다.

https://goo.gl/ydHspu

안녕하세요,

저는 Arch Linux에서 GTK3로 Electron 1.1.2를 컴파일할 수 있었고 use_gtk3=1 를 libchromiumcontent로 전달하고 brightray.gyp에서 gtk+-2.0 를 gtk+-3.0 로 변경할 수 있었습니다.

이제 Electron의 기본 앱은 키를 누를 때마다 충돌합니다.

자세한 내용은 https://github.com/tensor5/arch-atom을 참조하세요.

빌드 스크립트 리포지토리:
https://github.com/nikolowry/electron-gtk3

이번주말까지 마무리 되길 바랍니다. 그것은 WIP이며 아직 의미있는 것을 구축하지 못했습니다.

@EiNSTeiN 및 @tensor5 - https://github.com/nikolowry/electron-gtk3 가 지금 구축 중이 어야 합니다. debug 및 release 모두를 빌드하도록 특별히 지정하지 않는 한 release 버전

@zcbenz Debian Wheezy를 사용하는 데 역사적 이유가 있습니까(Chromium이 LTS와 호환되는 것을 좋아한다는 것을 알고 있습니다)? Jessie/GTK3를 사용하기 위해 빌드 플래그를 추가할까요? 당신이 아이디어에 반대하지 않는다면 적절한 풀 리퀘스트를 작업할 수 있습니다. 그렇지 않으면 적어도 GTK3를 빌드하는 데 필요한 참조 빌드 스크립트가 있어야 합니다.

편집: @tensor5 X 또는 Wayland를 사용하고 있습니까? Wayland의 주요 입력 이벤트에서 chromium gtk3 빌드가 충돌한다는 것을 알고 있습니다.

@nikolowry : 예, 저는 Wayland를 사용하고 있었고 실제로 X에서 잘 작동합니다. 감사합니다. 이 Chromium 문제가 어딘가에서 논의되었는지 알고 있습니까?

https://bugs.chromium.org/p/chromium/issues/detail?id=615164를 찾았습니다

@nikolowry 우리는 Chromium의 빌드 구성을 따르고 있으며 많은 Linux 배포판이 있으며 모든 것을 테스트할 수는 없지만 Chromium은 모든 곳에서 완전히 테스트되었으므로 Chromium을 따르는 것이 안전합니다.

저는 GTK+3용으로 빌드할 플래그를 추가하는 것이 좋고 빌드 스크립트에 대한 링크를 추가하는 것도 좋아 보입니다. Linux 빌드 지침의 고급 주제 중 일부일 수 있습니다.

@zcbenz는 좋게 들립니다. sysroot에 Wheezy 대신 Jessie를 사용하여 실행할 수 있는 Python 스크립트가 있지만 업스트림 Chromium에서 기본값으로 설정될 때까지 기다리는 것이 가장 좋습니다.

일반적으로 찾을 수 있는 가장 오래된 배포판을 기반으로 구축하는 것은 glibc++ 버전 관리로 인해 소프트웨어 배포와 관련하여 좋은 일입니다. Jessie로의 업그레이드는 (일반적으로 더 안전한 방법이라고 생각하지만) 과거. 우리는 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 지원 앱이었습니다. 그래서 내 Skylake 노트북이 혼합 dpi 모드에서 다중 모니터에 연결될 때 xrandr을 통해 더 이상 충돌하지 않게 되어 기쁩니다!!!!

편집: 일부 AUR 패키지도 유지 관리한다는 것을 알고 있으므로 "env GDK_BACKEND=x11"을 포함하도록 데스크탑 파일을 편집할 수 있습니다. 그러면 앱이 X와 Wayland에서 모두 실행될 수 있고 다른 모든 사람들은 많은 골칫거리를 줄일 수 있습니다. 미래!

@nikowry 이미 참여 중입니다!

결국 이것은 전자 소스에서 수정되어야 하며 런처 스크립트를 사용하는 것이 가장 우아한 방법은 아닙니다.

BTW AUR 패키지는 내 것이 아닙니다. 나는 저장소를 유지한다

@nikolowry Firefox도 Xwayland에 의존하는 GTK3 애플리케이션이지만 잘 작동합니다. 그래서 살펴보았습니다. 여기에서 볼 수 있듯이 먼저 X11 백엔드를 시도한 다음 감지된 display_name 을 gdk_display_open 합니다.

아마도 비슷한 일이 Chromium에서 수행될 수 있습니다.

기본 OS에서 pantheon-file-chooser를 사용하려면 GTK3가 필요합니다. 그렇지 않으면 다음을 얻을 수 있습니다.

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

Qt5-WebEngine을 지원/포트하지 않는 이유는 무엇입니까? 어쨌든 크롬 엔진을 사용하고 Qt에서는 모든 것이 gtk와 달리 훨씬 더 기본적으로 보입니다...

게다가 qt5는 gnome 개발 이외의 다른 것에 관심이 없기 때문에 매번 F**king API를 변경하는 gtk3처럼 항상 중단되지 않습니다.

여기에 gtk가 나쁘고 qt가 더 나은 이유 (2세지만 여전히 훌륭하고 관련성이 있음)에 대한

Qt 5.6.x는 이제 LTS에 있으며 라이센스 가 5.7로 변경되었습니다. 이는 오픈 소스 사용자/개발자에게 훨씬 좋습니다.

나는 개인적으로 왜 사람들이 gnome 외부에서 gtk를 사용하도록 설계되지 않았는지 이해하지 못합니다.

@ahjolinna 실제로 GTK+는 Gnome 외부의 애플리케이션 개발에도 사용됩니다. 어느 쪽이든 API를 QT로 변경하는 것은 Chromium 업스트림에서 많은 패치가 필요하기 때문에 Electron 팀에게 악몽이 될 것입니다. 수고할 가치가 없습니다.

기본적으로(?) 모든 GTK 개발자는 레드햇에서 고용한 GNOME 개발자이기 때문에 GTK+3은 본질적으로 GNOME과 결혼했습니다.

언급된 GTK API 파손은 red Hat이 GNOME을 앞으로 나아가는 것을 우선시하기 때문에 발생합니다. @ahjolinna 는 Qt5가 더 안정적이지만 _하지만_ 크롬 인스턴스에 대한 제한된 액세스만 제공한다는 것이 맞습니다.

그 이유는 또한 안정성입니다. 크롬 자체는 일부 영역에서 안정적인 API를 유지하기 위해 리소스를 투입할 수 있을 만큼 충분히 손상됩니다.

@nikolowry https://github.com/nikolowry/electron-gtk3 를 사용하여 gtk3 지원으로 전자를 구축하려면 atom-gtk3를 구축하기 위해 원자 구축에서 무엇을 변경해야 합니까?

gtk3 빌드를 사용하는 경우 밝은 테마를 사용할 때 메뉴 표시줄에 흰색 텍스트가 표시될 수 있습니다. 이 패치 는 문제를 해결합니다.

나는 다음 날에 다른 gtk3 빌드 경고를 고칠 것이다.

Chromium with Gtk2의 메뉴는 '네이티브 gtk 스타일'이 아니며 매우 추합니다. Gtk3 빌드가 이 문제를 해결할까요?

@멘시. 아니요, gtk3가 있는 메뉴 표시줄은 gtk2에서와 정확히 동일하게 보입니다. 당신 말이 맞아, 그것은 완전히 기본이 아니며 단순히 텍스트와 배경의 색상이 gtk 테마를 따릅니다.
나는 그것이 고칠 수 있는지 보기 위해 지난 날의 코드를 보았다. 한 가지 문제는 기본 gtk 코드가 크로스 플랫폼 래퍼 레이어 뒤에 숨겨져 있다는 것입니다. 아마도 gtk 전문가가 이에 대해 도움을 줄 수 있을 것입니다.

@tensor5 메뉴는 크로스 플랫폼 래퍼에서 구현되어야 한다고 생각합니다. OS X의 메뉴가 기본이고 기본 Cocoa 코드도 크로스 플랫폼 래퍼 레이어 뒤에 숨겨져 있는 것처럼.

@Menci 물론 그런 패치가 받아들여질 수 있는 유일한 방법입니다.

Gnome 앱 메뉴가 있으면 좋을 것입니다.

LibreOffice가 어떻게 했는지 볼 수 있습니다. 비슷한 방식입니다.

LibreOffice의 메뉴는 정말 네이티브가 아니라고 생각합니다. 그림자 및 표시/숨기기 애니메이션이 없습니다.

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

GTK+ 앱은 gnome(및 기타 gtk 파생 제품) 외부에서 기본적으로 보이지 않았으며 KDE, LXQt에서 항상 끔찍해 보였고 Unity 8이 도착하면(Qt5 기반) 동일한 문제가 발생합니다. KDE 팀은 이 문제로 gtk 팀과 협력하려고 시도했지만 그들은 완전히 100% 멍청했고 그들은 API가 모든 업데이트와 함께 변경/중단되는 것을 신경쓰지 않으며 그것이 (일부) KDE 항목을 깨뜨릴 것입니다. , 어떤 btw. gtk 팀의 어리석은 추론 때문에 하드코딩해야 했습니다.*

btw. KDE, LXQt 및 Unity 8 + Ubuntu Touch 및 SailfishOS를 사용하면 Qt5 "시장 점유율"이 gtk보다 훨씬 커지고 장기적으로 큰 영향을 미칠 것입니다.

추신. libreoffice에 대해 GTK 없이 빌드하고 기본 파일 선택기를 사용하도록 할 수 있습니다. 예를 들어 ChakraOS가 PKGBUILD 하는 이유는 무엇입니까? 가능한 한 GTK를 사용하지 않는 것을 좋아하는 KDE/Qt에 초점을 맞춘 배포판이기 때문에

편집

*GTK 개발자는 이전에 KDE에서 GTK 통합에 사용되었던 테마 엔진에 대한 액세스를 차단했습니다. 따라서 이제 유일한 방법은 "CSS 방식"을 시도하는 것입니다.

Qt를 사용하는 몇 가지 앱:
Dropbox, OBS, MEGA, VIber, Wireshark, makemkv, yacreader, masterpdfeditor, vapoursynth-editor, SVP, teampeak3, 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 빌드 스크립트 중 일부를 편집해야 합니다. 지금 기억) . 어렵지는 않지만 새 빌드를 할 때는 항상 지난 빌드에서 취한 몇 단계를 잊어버리는 것 같아서 항상 1분이 걸립니다.

@tensor5 가 자신의 arch-atom repo에서 gtk3를 사용하기 시작했다면 시도해 볼 것을 제안합니다. 그렇지 않으면 다음에 빌드를 수행하고 변경 사항을 문서화할 때 여기에 다시 나타나겠습니다. 주말)

@nikowry 감사합니다, 문서화된 변경 사항이 있으면 좋을 것입니다 :)

저는 Fedora를 사용 중이므로 이 Fedora copr을 기반으로 변경 사항을 통합하려고 합니다.

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 사양 파일을 분기). 물론 다른 누군가가 나를 이기지 않는 한 :)

나는 이것을 위해 gentoo ebuild를 작성하려고 노력하고 있지만 sucbess가 없습니다. 누군가가 나를 도와 주면 매우 감사 할 것입니다.

@eternal-sorrow 현재 공식 Gentoo 트리에 있는 ebuild인 dev-util/electron을 이미 보셨습니까?

@devurandom , 했습니다. 그것은 전자(0.36.12)의 아주 오래된 버전입니다. 현재 버전(1.3.1)에 맞게 수정하고 모든 패치를 적용했지만 여전히 v8 연결 문제(많은 정의되지 않은 v8 기호)가 발생합니다.

@영원한 슬픔

1. 해당 패키지의 관리자인 [email protected]에게 연락하십시오.
2. 여기 GH에서 ebuild로 오버레이 저장소를 설정하세요. 함께 해결할 수 있습니다.

Arch Linux에서 @eternal-sorrow GTK3로 최신 버전의 Electron을 빌드 합니다. 한 번 살펴보세요.

이에 대한 진전이 있습니까?

@nikolowry , atom-gtk3에서 사용 중인 원자 및 전자 버전은 무엇입니까? 나는 현재 버전의 원자에는 전자-0.37이 필요하며 현재 버전의 전자로는 실행할 수 없다는 것을 깨달았습니다. 내가 잘못?

@eternal-sorrow Atom은 최근 Electron의 최신 버전으로 업데이트되었습니다.

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

gtk3를 사용하는 방법이 있습니까? 더 나은 파일 대화 상자를 위해 특히 좋아할 것입니다.

아치리눅스에는 이미 gtk3 빌드가 있기 때문에 전자 코어가 없는 것은 무엇입니까?

나는 그들이 스위치가 업스트림에서 일어나기를 원한다고 생각합니다. 그리고 공식적으로 계획되어 있습니다( https://chromium.googlesource.com/chromium/src/+/acc4214c4dece4e70fb53355d557bd45f35965d6/docs/linux_gtk_theme_integration.md#GTK3 참조).

추가 정보, chromium/google chrome dev 채널은 gtk 3을 사용하므로 이제 시간 문제입니다.

https://bugs.chromium.org/p/chromium/issues/detail?id=79722#c110 에서 Chrome 59에 대해 확인되었습니다

이제 시간문제...

크롬 59가 나왔습니다! :따다:

이제 Chrome 59가 출시되었으므로 Linux용 GTK3으로 빌드된 Electron 시험판을 보는 것이 좋습니다.

GTK3 지원은 이제 Chromium stable(59)에서 지원 됩니다. 즉, 곧

몇 가지 질문이 있습니다.

• GTK3 지원을 원하는 이유는 무엇입니까?
• 이 스레드에서 많이 언급된 "파일 대화 상자"를 봅니다. GTK2에서 무엇이 잘못되었고 GTK3에서 어떻게 개선되었습니까?
• 이 업데이트는 성능, 호환성 등을 개선합니까? 아니면 그냥 UI?
• 사람들이 기대할 수 있는 다른 개선 사항은 무엇입니까?
• 어떤 Linux 배포판에서 GTK(3)를 사용합니까?

@zeke :

GTK3 지원을 원하는 이유는 무엇입니까? 이 스레드에서 많이 언급된 "파일 대화 상자"를 봅니다.

내가 관심을 갖고 있는 한 가지 개선 사항은 Flatpak 샌드박스 내에서 실행되는 Electron 애플리케이션이 이제 호스트의 파일 선택기에 대한 포털 을 원활하게 사용할 수

이 업데이트는 성능, 호환성 등을 개선합니까? 아니면 그냥 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 응용 프로그램은 현재 데스크톱과 더 잘 통합됩니다. 파일 선택기 대화 상자가 좋은 예입니다.

@zeke

GTK3 지원을 원하는 이유는 무엇입니까?

저는 일관성을 중요하게 생각합니다. GTK 3에서는 파일 대화가 상당히 다르며, GTK 버전 간에 테마가 약간 일치하지 않는 경우가 많습니다. 나는 또한 시스템을 최소한으로 유지하는 것을 좋아합니다. Atom이 GTK 2를 삭제하면 GTK 2를 설치해야 할 이유가 하나 줄어듭니다.

이 스레드에서 많이 언급된 "파일 대화 상자"를 봅니다. GTK2에서 무엇이 잘못되었고 GTK3에서 어떻게 개선되었습니까?

위와 같이 나에게 가장 중요한 것은 일관성이다. GTK 3 대화 상자는 디렉토리에서 증분 검색 대신 재귀적 이름 검색을 사용하기 때문에 실제로 일부에서는 열등한 것으로 간주됩니다.

사람들이 기대할 수 있는 다른 개선 사항은 무엇입니까?

메뉴는 니모닉 을 지원하지 않고 화살표 키를 사용하여 인접한 메뉴 사이를 이동하는 사용자 지정 구현 대신 GTK도 사용해야 합니다.

Atom이 GTK 2를 삭제하면 GTK 2를 설치해야 하는 이유가 하나 줄어듭니다.

@jtojnar : 기본적으로 GTK3를 사용하는 최신 버전의 Linux가 있는 경우 GTK3로 업데이트되지 않은 앱을 지원하려면 GTK2를 수동으로 설치해야 합니까? Atom(및 다른 모든 Electron 앱) 외에 이 문제가 있는 다른 인기 있는 앱은 무엇입니까?

@zeke 종속성 설치는 일반적으로 배포판의 패키지 관리자에 의해 자동으로 수행되며, GTK 3 앱을 설치하면 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 및 곧(tm) XFCE와 같은 많은 주요 데스크톱 환경에서도 GTK3을 사용합니다.

이를 위한 전제 조건은 #9946에 대한 pull 요청이 있는 Chromium 59입니다.

@zeke 주요 요점은 Linux에서 GTK(2 또는 3) 또는 Qt를 UI 툴킷으로 사용하는 앱을 볼 가능성이 더 높기 때문에 UI 일관성이 더 우수하다는 것입니다. Windows와 macOS에는 고유한 기능이 있으며 일반적으로 해당 플랫폼의 대부분의 앱이 이를 사용한다는 것을 알 수 있습니다. 예를 들어 기본 UI 툴킷을 사용하지 않기 때문에 Steam에는 기본 모양이 없습니다.

이 스레드에서 많이 언급된 "파일 대화 상자"를 봅니다. GTK2에서 무엇이 잘못되었고 GTK3에서 어떻게 개선되었습니까?

GTK3와 비교한 GTK2는 UI가 다른 시각적 모양(파일 브라우저와 같은 레이아웃/기능 차이)을 가진 이전 버전의 Windows 또는 macOS로 가장 잘 설명될 수 있습니다. Windows 10을 실행하고 Windows Vista 또는 XP처럼 보이는 파일 대화 상자가 나타나면 위치가 맞지 않고 특정 기능/UX가 부족할 수 있습니다.

KDE와 같은 데스크탑 환경(DE)에서 이는 여전히 해당 DE, Qt에 대한 보다 일반적인 툴킷 대신 GTK3 대화 상자를 생성합니다. 그래서 거기에는 여전히 약간의 불일치가 있지만 GTK2보다 낫습니다.

다음은 기본 Breeze 테마가 있는 KDE의 몇 가지 예입니다.

현재 Electron 앱이 있는 GTK2 대화 상자 - GitKraken:

GTK3 대화 - 혼합:

Qt 대화 - 케이트:

Mono/.NET(?) 대화 상자 - BundleModder - Linux에서 흔하지 않은 Java 응용 프로그램도 흔하지 않은 툴킷을 사용할 수 있습니다.

보시다시피 스타일 일관성은 UI 툴킷에 따라 상당히 다릅니다. 일반 사용자가 왜 다른지 혼동을 일으킬 수 있으므로 동일한 목적을 위한 것인지 아니면 탐색/프레젠테이션 세부 정보가 서로 다른 것에 대해 불만을 가질 수 있습니다(GTK는 두 번 클릭할 수 있지만 Qt는 단일용으로 설정할 수 있습니다. 폴더 탐색 클릭) 또는 일관성 부족을 비전문가로 보는 것입니다.

Gnome(GTK 기반 DE)는 GTK3와 Qt 간의 일관성을 유지하면서 KDE(Qt 기반 DE)보다 이를 더 잘 처리할 수 있습니다. Qt의 툴킷은 기본 느낌/경험을 제공하는 플랫폼 간에 잘 통합되도록 설계되었기 때문입니다. GTK 개발자는 KDE 개발자가 DE에서 문제를 해결하기 위해 코드를 제공하기를 원함에도 불구하고 Gnome 이외의 DE에서 툴킷을 지원하는 것을 꺼립니다. 사용자가 GTK2 또는 흔하지 않은 툴킷을 사용하는 이전 애플리케이션을 사용하지 않는 경우 더 나은 경험을 할 수 있습니다.

툴킷이 다른 툴킷에 상응하는 앱만큼 강력하지 않은 경우 GTK와 Qt 앱이 혼합되어 있는 경우가 종종 있습니다. 일부 사용자에게는 단일 툴킷 앱만 사용하는 것이 가능합니다(KaOS는 Qt5에 맞는 배포판입니다. Chrome과 같은 선택적 GTK 앱을 사용할 수 있음). Electron 애플리케이션의 인기로 인해 GTK를 피하는 것이 항상 바람직한 것은 아닙니다.

GTK3 지원을 원하는 이유는 무엇입니까?

일관성, 파일 대화 상자는 KDE 사용자인 저에게 가장 눈에 띄는 것입니다.

이 업데이트는 성능, 호환성 등을 개선합니까? 아니면 그냥 UI?
사람들이 기대할 수 있는 다른 개선 사항은 무엇입니까?

FlatPak(Sandboxed, distro-agnostic 앱, GUI 앱용 Docker/컨테이너와 같은)에 대해 많이 알지는 못하지만, DE(FlatPak 테마는 또 다른 일관성을 위한 이야기, FlatPak의 GTK3는 최근에 테마 지원을 받았고 다른 툴킷도 이를 추가해야 합니다). 언급한 FlatPak은 포털 지원을 통해 파일 대화 문제를 완화할 수도 있습니다.

개인적으로 GTK2와 GTK3에 대해 잘 모르지만 HiDPI 이야기는 GTK3에 더 좋을 것입니다. 테마 지원 제 생각에는 더 나은 것 같거나 적어도 앞으로 GTK3용 테마를 2보다 더 많이 얻을 가능성이 더 큽니다. Gnome에서 파일 대화 상자는 해당 사용자의 UX를 개선하는 클라이언트 측 장식(CSD)과 약간 다를 수 있습니다. 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에서 손상되었습니다.
그래도 최신 마스터에서는 작동합니다.

그리고 btw, 더 이상 공식적으로 유지 관리되지 않습니다.
https://groups.google.com/a/chromium.org/d/msg/chromium-dev/iO3qzex6oYA/Q-i4Cie3BwAJ

GTK3의 장점에 대한 멋진 피드백입니다. 입력해 주셔서 감사합니다.

불행히도 GTK3 업데이트는 Chrome 59가 있는 Electron 1.8에 포함되지 않는 것 같습니다. 현재 빌드를 차단하고 있으므로 GTK3가 지원되기 전에 다음 Chromium이 61로(60을 건너뛸 때까지) 기다려야 합니다. 전자에서.

맞습니까, @alexeykuzmin?

@zeke 크롬 61 범프가 언제 발생할지 대략적으로 예측할 수 있습니까? 해당 릴리스에 맞춰 기본 ES6 웹 구성 요소로의 이동을 계획하고 싶습니다. 역사적으로 충돌은 출시 후 한 달 정도 후에 발생합니까?

@zeke
예, Chromium 59 분기의 GTK3에 문제가 있었습니다.
그러나 다가오는 Chromium 61 업그레이드에서 GTK2에서 GTK3으로 전환해야 합니다.

@cpoole 우리는 현재 Chromium 61이 Electron에 상륙할 시기를 예측하지 https://github.com/electron/libchromiumcontent/pull/335 에서 작업 중입니다 @tonygach , @cifratila , @alexeykuzmin , @alespergl , 기타?)이 이 프로세스를 돕고 있어 GitHub의 Electron 팀이 CI를 개선하고 Electron 릴리스 프로세스를 원활하게 하는 데 집중할 수 있습니다. 그래서 저는 낙관적입니다 :)

GTK3 지원을 원하는 이유는 무엇입니까?

@deikatsuo 무슨 브라우저인가요? 크롬과 에피파니가 아기를 낳은듯...

@mdsiton 에피파니 👍

이것에 대한 소식이 있습니까?

@ziggy42 최신 크롬 61(https://github.com/electron/electron/pull/10213)에 이미 있어야 합니다. 마스터에서 병합하고 어느 시점에서 릴리스하는 것뿐이라고 생각합니다.

기다릴 수 없어, 그 못생긴 파일 선택기가 내 눈을 불태운다 :fire:

이 변경으로 인해 Electron 앱에서 CSS가 허용됩니까?

그래서 크롬 61이 합쳐졌는데 gtk3도 같이 나오나요?

Electron은 현재 마스터 브랜치에서 GTK3을 사용하고 있으며 다음 마이너/메이저 릴리스에서 제공될 예정입니다.

@ahjolinna

이 토론에 약간의 정신을 바쳐 주셔서 감사합니다.

이미 언급한 KaOS에 관심이 많을 수 있습니다.
그것은 몇 년 동안 Chakra를 위대하게 만든 바로 그 사람, IMHO에 의해 유지됩니다.

@모두

GTK+ 3는 언제 출시되었나요?

7년 전.

잠시 동안 입에서 녹도록하십시오.

그리고 수많은 소프트웨어 프로젝트가 여전히 2위에 있습니다.
이식은 즐거움이기 때문에..

XFCE, Mate 및 기타 많은 사람들이 코드를 이식하는 데 6년이 걸렸습니다.
다른 프로젝트는 2 이내에 GTK에서 Qt로 완전히 전환되었습니다.

그리고 그렇습니다: GTK+는 GNOME에 의해 개발되었으며 repo도 거기에 있습니다.
본질적으로 정의에 따라 GNOME용으로 개발되었으며 그 밖의 것은 아닙니다.

Qt는 여러 플랫폼에 대한 진정한 기본 통합을 위해 개발되었습니다.

전자는 무엇입니까?

그놈 가게?

좋은 것.

영리한 생각.

명령형 프로그래밍과 함수형 프로그래밍은 물론 이 장면의 다른 많은 측면에서도 동일합니다. 중복되고 오래되고 오래된 소프트웨어는 종종 중독성 약물로 취급되어 중독성이 있습니다.

그리고 새롭고 영리하고 혁신적인 소프트웨어는 오해와 순수한 무지에 의해 다루어집니다.

10, 12개의 프로젝트가 GTK+에서 Qt로 전환된 반면, 반대의 경우가 한 번도 없었습니다.

이것이 다시 혀에서 녹게 하십시오. 즉, 통합된 전체 UI 코드를 완전히 다시 작성해야 합니다.
자주 중첩됩니다.

즉, 기존 도구의 주요 업그레이드와 비교하여 선호합니다.
그리고 그들 모두는 오늘까지 그 결정에 만족합니다.

그들에게 묻다.

대안을 고려하지 않고 무리를 따르기 전에.

@ahjolinna 가 VLC, Wireshark, LXQt 및 기타 놀라운 소프트웨어 프로젝트도 이전에 GTK를 기반으로 하는 이들 중 한 사람의 비디오를 게시했습니다.

GTK는 Chromium에서 Aura에 대한 바인딩으로 사용되며 이는 Linux/freeBSD/Solaris에서만 사용됩니다.
Windows 및 macOS 빌드에는 무료입니다.

:눈짓:

@ShalokShalom 의 요점을 얻었

포크 버튼은 상단에 있습니다 btw, 자유롭게 느끼십시오.

예, 이것은 불필요하게 연마되었습니다.

하지만 동의합니다. GTK에는 통증을 유발하는 불필요한 파손이 너무 많으니 Qt가 더 나은 선택이었을 것입니다.

• IF QtWebEngine이 기본 크롬 인스턴스에 대한 충분한 액세스를 제공합니다.
• IF QtWebEngine는 신속하게 최신 크롬을 추적

토론을 더 적절한 곳으로 옮기는 것이 좋습니다. @ShalokShalom , 여기에서 새 문제를 열고 지금보다 더

VLC , Wireshark, LXQt 및 기타 놀라운 소프트웨어 프로젝트도 이전에는 GTK를 기반으로 했습니다.

그건 사실이 아니다. VLC는 GTK가 아닌 Qt 이전에 wxWidgets를 사용하고 있었습니다: https://wiki.videolan.org/WxWidgets_Interface/

내 생각에 GTK 사람들은 꽤 오랫동안 3.x 시리즈에서 파손 및 버전 관리에 대해 충분히 잘 전달하지 못했다는 것을 인정했으며 https:// 에서 읽을 수 있는 것처럼 더 좋고 더 명확한 장기적 안정성으로 미래에 더 열심히 노력할 것입니다

또한 Qt와 GTK는 역사와 배경, 목표가 다르기 때문에 1:1로 공정하게 비교할 수 없다고 말씀드리고 싶습니다. 제 생각에는 둘 다 관점에 따라 장단점이 있습니다.

GTK가 GNOME 프로젝트만을 위해 만들어졌다는 것도 제 생각에는 불공정한 총괄적 진술입니다.

하아! 나는 그 계획에 대해 정말로 몰랐다. 드디어 배운 것 같습니다. 그들이 CSS의 모든 주요 변경 사항을 고려하기 시작하기를 바랍니다. 실제 주요 변경 사항입니다.

내가 마지막으로 들은 것은… 음… 편심 GTK 4.0은 GTK 4가 아닙니다 . 그래서 마침내 거의 semver만큼 좋은 것에 도달했습니다! 그들은 20년 전에 Qt가 했던 것과 거의 같은 일을 합니다! 😁

이 트위터 게시물을 기반으로 곧 기본적으로 기본 GTK3 지원이 포함된 Electron을 볼 수 있습니다.

Electron 2.0.0-beta.1은 업데이트된 Chromium 및 Node.js, macOS 인앱 구매, Linux용 GTK3 지원 등으로

예. 이에 대한 실제 작업은 Chromium 작성자가 수행했으며 Electron은 Electron 2.0.0의 Chromium 업그레이드를 통해 이를 얻었습니다.

또한 Electron의 자체 코드는 https://github.com/electron/electron/pull/11879 에서 GTK3ified를 받았습니다.

예, 이것은 불필요하게 연마되었습니다.
하지만 동의합니다. GTK에는 통증을 유발하는 불필요한 파손이 너무 많습니다, Qt
더 나은 선택이 되었을 것이다
IF QtWebEngine이 기본 크롬 인스턴스에 대한 충분한 액세스를 제공합니다.
QtWebEngine이 최신 Chromium을 충분히 빠르게 추적하는 경우

글쎄, 이것이 주요 문제입니다. 사람들은 가장 빨리 구현하는 것이 좋다고 생각하지만 실제로 실행하기 위한 구현은 장기적인 유지 관리와 매우 다르다는 사실을 자주 잊습니다.

언급된 문제를 해결할 수 있다는 것은 내 관점에서 볼 때 매우 명확합니다.

GTK3 포트에서 실제로 작업하는 코더의 수와 전체 UI 코드를 새 툴킷에 이식하는 코더의 수를 비교하면 그 차이가 얼마나 놀라운지 알 수 있습니다. 이미 'GTK에서 Qt로: 이상한 여정'이라는 동영상을 게시한 것 같습니다.

Qt의 지원을 해킹하는 대신 단순히 사용할 준비가 된 것처럼 보이기 때문에 구식 소프트웨어에 집중하는 이유는 무엇입니까?

그것은 장기적인 결정을 완전히 무시하는 '나는 _보이는_ 준비된 것을 사용한다'는 교리입니다. 예, 처음에는 조금 더 많은 노력이 필요한 것처럼 보일 수 있지만 일단 구현되면 최신 툴킷의 이점을 확실히 누릴 수 있습니다.

QtWebEngine이 Chrome을 그렇게 빨리 따라가지 않는다는 것도 그렇게 과감하지 않습니다.
충분히 빠르며 Qupzilla는 특히 KaOS와 같은 적합한 환경에서 놀라운 작업을 수행할 수 있음을 증명합니다.

Qupzilla 및 기타 소프트웨어가 단일 코더로 유지 관리되는 놀라운 소프트웨어를 제공하는 것으로 입증되었기 때문에 '기본 Chromium에 대한 더 많은 액세스'가 필요하고 'QtWebEngine이 Chromium을 충분히 빠르게 따르지 않습니다'라고 생각하십니까?

Electron의 완전한 웹 브라우저로서 더 많은 액세스와 더 빠른 팔로잉이 필요하다고 생각하십니까? 어때요?

이제 많은 프로젝트에서 이 서투른 소프트웨어 스택에 앉아 있고 소규모 팀은 깊이 중첩된 코드의 40-60%를 Qt로 빠르고 효율적으로 이식할 수 있습니다.

GTK 2에서 GTK 3까지 그들이 처리하지 못한 일, 이는 매우 놀라운 일입니다. 말했듯이: 대부분의 프로젝트는 주요 버전 을

그리고 거의 모든 사람들이 그것을 무시하는 것 같습니까? 처음에 과학 커뮤니티에서 원시적인 결정이 계속해서 퍼졌다는 것은 너무 슬픈 일입니다.

평화 :)

@ShalokShalom , "오래된 소프트웨어"는 무엇을 의미합니까? GTK+? 그런 말을 하는 이유가 있나요?

이 Qt 스팸은 그만해 주세요. 이것은 GTK 3 포트에 관한 문제입니다. 유지 관리자에게 Qt로 전환하도록 설득할 필요가 있다고 생각되면 별도의 문제를 엽니다. Qt 팬보이의 메시지가 아닌 구현 진행 상황에 대한 뉴스를 받고 싶습니다.

과도한 주제 외 토론으로 인해 이 대화를 잠급니다.

잠금은 증상만 해결하지만 GTK3로의 이동이 마무리되고 GTK2에서 GTK3으로 이동하는 이 문제의 주제에 대해 논의할 내용이 많지 않기 때문에 합리적이고 빠른 수정입니다.