Electron: Рассмотрите возможность замены GTK2 на GTK3 в сборках Linux

После обновления до Chrome 47 это звучит хорошо.

Chrome 47 был выпущен три дня назад. :) http://googlechromereleases.blogspot.se/2015/12/stable-channel-update.html

Немного покопался в этом, но все еще не уверен, где поставить флаг use_gtk3 ..

@zcbenz или

Я не являюсь экспертом в построении поведения системы сборки для Chromium, но, прочитав там ошибку, связанную с Chromium , все будет в порядке, мы добавим ее в variables в common.gypi . Соответствующая строка находится здесь .

На самом деле я тестирую и это на Linux. В моем текущем модуле разработки работает Elementary OS , и всякий раз, когда запускается приложение Gtk2, отображается предупреждение Gtk-Message: Failed to load module "pantheon-filechooser-module" ( Ref ). Если все пойдет гладко (надеюсь), посмотрим, смогу ли я тоже получить пиар. Тем не менее, определенно понравился бы ваш вклад.

Есть новости по этому поводу? Как пользователь Atom я бы хотел, чтобы он использовал GTK3 вместо GTK2.

@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 на моем компьютере. В моем случае мое первоначальное намерение - создать сборку Electron, которая не будет выдавать ошибки в моем модуле разработки (который работает под управлением Elementary OS Freya). Однако кажется, что такое построение на самом деле не устранит предупреждение.

в # 4642 @zcbenz сказал:

Флаг use_gtk3 имеет смысл только на стороне Chromium, чтобы включить GTK3, нам нужно сначала включить его в libchromiumcontent, а затем изменить настройки ссылки в Electron.

так что именно нужно делать?

1. позволяют использовать GTK3 в libchromiumcontent: будет добавлять флаг в chromiumcontent.gypi быть достаточным? это важно или электрон не использует эту сборку мишени?
2. изменить настройки ссылки в Электрон: где это сделать?

Я не эксперт в этой области и не уверен, что неправильно понял комментарий

По вопросам:

1. Возможно нет. На первый взгляд набором скриптов, которые загружают исходный код хрома из апстрима , патчей и переупаковок для использования в Atom. Помимо изменения флага на chromiumcontent.gypi, как вы упомянули, по крайней мере библиотеки зависимостей также правильно упакованы . См. Экземпляры libgtk2ui .
2. В Electron есть @zcbenz , вероятно, относятся к ним.

Ошибка отслеживания в Chromium отражает какой-то статус от апстрима. Один из комментаторов отмечает:

IIRC, потребуется создать библиотеку libgtk3ui, соответствующую chrome / browser / ui / libgtk2ui /, и переключить эти две библиотеки во время запуска.

И на момент написания libgtk3ui еще не существует :( Вы также можете посмотреть код на libgtk2ui.

Я был между личными ноутбуками после того, как я изначально разместил это, и с тех пор использовал MBP, выпущенный моей компанией, в течение нескольких месяцев. Но у меня наконец-то появилась моя новая машина, время простоя, и я решил нанести удар по этому поводу. Мой прогресс на данный момент:

Мне удалось получить libchromiumcontent для сборки с помощью gtk3, это повлекло за собой следующее:

• добавить 'use_gtk3': 1 в файл chromiumcontent.gypi.
• отключил sysroot, вручную закомментировав вызов install_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 и обновление любых других файлов gyp для использования моих системных библиотек, а не sysroot.

Что касается libgtk2ui - мне сложно найти ссылку на то, где я это читал (возможно, форумы gentoo, трекер проблем с хромом или ветка сообщества Arch Linux), но я считаю, что Chromium создает libgtk2ui независимо от gtk3 / gtk2, потому что разработчики делали минимум, чтобы заставить работать сборку с gtk3. Я могу ошибаться и не знаю, как это может повлиять на патчи на основе Electron, написанные специально для gtk2.

Я делаю еженедельную сборку chromium-gtk3 для своего личного браузера, и libgtk2ui все еще присутствует, и я предполагаю, что она уже используется.

Я вернусь сюда, надеюсь, в ближайшие несколько дней и свяжусь с моим репозиторием POC с готовыми двоичными файлами и некоторыми снимками экрана.

Готово, и я надеюсь, что atom-gtk3 скоро будет запущено!

Самым большим препятствием было использование debian_wheezy_sysroot в libchromiumcontent / electronic / brightray. Сопровождающим этих репозиториев, вероятно, потребуется некоторое обсуждение и принятие решения о том, следует ли переходить на jessie или, возможно, сделать sysroot необязательным.

На выходных я попробую собрать скрипт node или bash для создания распространяемого исполняемого файла Electron 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 , спасибо за вашу работу. Где-нибудь есть исходный код? Я хотел бы подготовить PPA, чтобы облегчить жизнь нам, пользователям Ubuntu.

Я также хотел бы добавить, что эта проблема касается не только предоставления современных виджетов. GTK2 не может использоваться в системах HiDPI (по крайней мере, в ubuntu 16.04) из-за того, что все значки на кнопках и панелях инструментов отображаются чрезвычайно маленькими. К счастью, в случае с Atom это, по-видимому, влияет только на диалог открытия файла, по крайней мере, насколько я могу судить, поэтому сам Atom остается вполне пригодным для использования.

@EiNSTeiN Вскоре я сделаю ссылку на репозиторий electronic-gtk3 к концу уик-энда.

Сначала небольшая предыстория - основная причина, по которой я был полон решимости заставить это работать, заключалась в том, что я использую Atom в качестве ежедневного драйвера и больше не могу видеть диалоговое окно файла! Однако эта сборка заняла больше времени, чем ожидалось, из-за сложностей с asar / compiled-cache / npm-not-running-post-install-scripts, но сейчас я готов.

Я обдумывал лучший способ сделать это - чтобы у сопровождающих был хороший справочник (было бы сложно координировать запросы на вытягивание во всех отдельных репозиториях), а также чтобы gtk3-потенциальные пользователи могли начать работать как быстро невозможно.

Но я не буду делать автоматические сборки, поэтому каждый должен быть готов к 4-6 часам сборки или к подготовке нескольких серверов. Я мог бы время от времени выпускать релизы, пока эти изменения не отразятся в официальном репо.

Я сузился до создания репо с электроном в качестве подмодуля и написания единственного сценария bash для создания электрона со всеми достоинствами gtk3. Тогда у каждого дистрибутива может быть легкая отправная точка для распространения пакетов до тех пор, пока эти изменения не будут официально внесены.

И на заметку о hidpi - мой exec cmd для atom-gtk3 равен 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

Привет,

Мне удалось скомпилировать Electron 1.1.2 с GTK3 на Arch Linux, передав use_gtk3=1 в libchromiumcontent и изменив gtk+-2.0 на gtk+-3.0 в brightray.gyp .

Теперь приложение Electron по умолчанию вылетает всякий раз, когда я нажимаю клавишу.

Подробности здесь: https://github.com/tensor5/arch-atom.

Репозиторий сценария сборки:
https://github.com/nikolowry/electron-gtk3

Надеюсь, он будет завершен к концу недели. Это WIP, и он пока не создает ничего значимого.

@EiNSTeiN и @ tensor5 - https://github.com/nikolowry/electron-gtk3 должны быть созданы . Обратите внимание, что он строит только версию release если вы специально не указали ему, что нужно строить как debug и release . просмотрите README и откройте вопрос, если что-то не работает.

@zcbenz есть ли историческая причина в использовании Debian Wheezy (я знаю, что Chromium любит LTS-совместимость)? Может быть, добавить флаг сборки для использования Jessie / GTK3? Я мог бы поработать над правильным запросом на перенос, если вы не против этой идеи, в противном случае у вас есть хотя бы эталонный скрипт сборки о том, что нужно для сборки GTK3.

Изменить: @ tensor5 вы используете X или Wayland? Я знаю, что сборки хрома gtk3 дают сбой при ключевых событиях ввода в Wayland.

@nikolowry : да, я использовал Wayland, и он действительно отлично работает с X, спасибо. Вы знаете, обсуждалась ли где-нибудь эта проблема Chromium?

Нашел это: https://bugs.chromium.org/p/chromium/issues/detail?id=615164.

@nikolowry Мы просто следим за конфигурациями сборки Chromium, существует множество дистрибутивов Linux, и мы не можем протестировать их все, в то время как Chromium полностью протестирован повсюду, поэтому следовать Chromium безопасно.

Я хорошо добавляю флаг для сборки для GTK + 3, и добавление ссылки на ваш сценарий сборки тоже мне нравится. Это может быть частью расширенных тем инструкции по сборке Linux .

@zcbenz звучит хорошо - у них есть сценарий python, который можно запустить, который использует Jessie вместо Wheezy для sysroot, но я думаю, что лучше подождать, пока он будет установлен по умолчанию в исходном Chromium.

В общем, построение на самом старом дистрибутиве, которое вы можете найти, - это хорошо, когда дело доходит до распространения программного обеспечения из-за управления версиями glibc ++ - обновление до Jessie может (хотя в целом я считаю это более безопасным) осиротевшие люди, в которых работал Electron. прошлое. Мы часто сталкиваемся с этой проблемой с пользователями RHEL

@ tensor5 разобрался, как запускать в Wayland. Я прокомментировал этот билет Chromium и обновил репозиторий gtk3.

Просто нужно запустить GDK_BACKEND=x11 electron поскольку Chromium не подключается к модулю XWayland автоматически.

@nikolowry УДИВИТЕЛЬНЫЙ!

Итак, если я правильно понимаю, проблема в том, что GTK3 думает, что электрон - это чистое приложение Wayland, а это не так.

@ tenor5 точно! GTK3 предполагает, что все приложения, использующие этот инструментарий, готовы к работе с Wayland (таким образом, они отвечают за загрузку XWayland при необходимости).

В эти выходные я готовился погрузиться в исходный код Chromium, чтобы разобраться в этом, и, пытаясь сгенерировать журналы, я наткнулся на простое решение через https://fedoraproject.org/wiki/How_to_debug_Wayland_problems.

Chromium и Atom были моими последними приложениями, не поддерживающими Wayland - так что рад, что мой ноутбук Skylake больше не будет вылетать из-за xrandr при подключении к нескольким мониторам в режиме смешанного dpi !!!!

Изменить: я знаю, что вы также поддерживаете некоторые пакеты AUR, поэтому вы можете отредактировать файлы рабочего стола, включив в них «env GDK_BACKEND = x11», это позволит приложениям работать как в X, так и в Wayland и избавит всех от множества головных болей в будущее!

@nikolowry Я уже на нем!

В конце концов, это должно быть исправлено в источнике электронов, использование скрипта запуска - не самый элегантный способ.

Кстати, пакет AUR не мой. Я поддерживаю репозиторий

@nikolowry Firefox - это тоже приложение GTK3, основанное на Xwayland, но оно отлично работает. Итак, я взглянул на него: как вы можете видеть здесь, он сначала пробует бэкэнд X11, а затем использует обнаруженное display_name для gdk_display_open .

Наверное, то же самое можно сделать в Chromium.

В elementary OS нам понадобится GTK3 для использования pantheon-file-chooser, иначе мы получим следующее:

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

почему бы просто не поддержать / портировать на Qt5-WebEngine ? он все равно использует движок хрома, и на Qt все выглядит более родным, чем на gtk ...

плюс qt5 не всегда ломается, как gtk3, который каждый раз меняет свои F ** king API только потому, что их не волнует ничего, кроме разработки gnome.

вот отличная видеопрезентация, почему gtk плохой, а qt лучше (двухлетний старый, но все еще хороший и актуальный)

Qt 5.6.x теперь находится в LTS, и их лицензия изменена на 5.7 , что намного лучше для пользователей / разработчиков с открытым исходным кодом.

Я лично не понимаю, почему люди используют gtk за пределами gnome, если он не предназначен для этого.

@ahjolinna На самом деле GTK + также предназначен для разработки приложений вне Gnome. В любом случае изменение API на QT было бы кошмаром для команды Electron, поскольку для этого потребовалось бы много исправлений из восходящего потока Chromium. Это не стоит проблем.

GTK + 3 _is_ внутренне женат на GNOME, поскольку в основном (?) Все разработчики GTK являются разработчиками GNOME, нанятыми красной шляпой.

Упомянутая поломка GTK API происходит потому, что красная шляпа отдает приоритет продвижению GNOME вперед. @ahjolinna прав в том, что Qt5 более стабилен, но _ но он предоставляет только ограниченный доступ к экземпляру хрома.

Причина также в стабильности: хром сам по себе ломается настолько, что они могут использовать свои ресурсы только для поддержания стабильного API в некоторых областях.

@nikolowry, если бы я использовал https://github.com/nikolowry/electron-gtk3 для создания электрона с поддержкой gtk3, что мне нужно было бы изменить в сборке атома, чтобы построить атом-gtk3?

Для тех, кто использует сборку gtk3, вы, вероятно, увидите белый текст в строке меню при использовании светлой темы. Этот патч решает проблему.

Я собираюсь исправить другие предупреждения сборки gtk3 в ближайшие дни.

Меню в Chromium с Gtk2 не является «родным стилем gtk» и очень некрасиво. Исправит ли это сборка Gtk3?

@Menci. Нет, строка меню с gtk3 выглядит точно так же, как с gtk2. Вы правы, он не полностью нативен, просто цвета текста и фона соответствуют теме gtk.
Я смотрел код в прошлые дни, чтобы увидеть, можно ли это исправить. Одна из проблем заключается в том, что собственный код gtk скрыт за слоями кроссплатформенных оболочек. Возможно, специалисты по gtk могут помочь с этим.

@ tensor5 Я думаю, что меню нужно реализовать в кроссплатформенных оболочках. Точно так же, как меню OS X является родным, а собственный код Какао также скрыт за слоями кроссплатформенных оболочек.

@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, такие как тема breeze-gtk , который, кстати,. пришлось жестко запрограммировать из-за глупых рассуждений команд gtk. *

Кстати. с KDE, LXQt и Unity 8 + Ubuntu Touch и SailfishOS «рыночная доля» Qt5 стала намного больше, чем gtk, и это окажет огромное влияние, по крайней мере, в долгосрочной перспективе

PS. насчет libreoffice, вы можете создать его без GTK и использовать собственный filepicker, это то, что, например, делает ChakraOS, PKGBUILD , почему? потому что его дистрибутив, ориентированный на KDE / Qt, старается избегать использования GTK в максимально возможной степени.

отредактировал

* Разработчики GTK заблокировали доступ к движкам тем, которые ранее использовались для интеграции GTK в KDE, поэтому теперь единственный способ - попробовать «метод CSS»

несколько известных мне приложений, использующих Qt:
Dropbox, OBS, MEGA, VIber, Wireshark, makemkv, yacreader, masterpdfeditor, vapoursynth-editor, SVP, teampeak3, mkvtoolnix-gui, hplip, scribus WPS-office ...

другие DE, использующие Qt5: http://papyros.io/ и https://lumina-desktop.org/

@ahjolinna Я думаю, вы пытаетесь убедить не тех людей. Если Chromium не переключится, я очень сомневаюсь, что Electron переключится. Просить команду Electron поддерживать этот проект, а также форк QT5 для Chromium - это слишком многого.

Кроме того, эта проблема связана с заменой GTK2 на GTK3. Если вы хотите, чтобы они рассмотрели возможность перехода, создайте новый выпуск. Иначе это не по теме и засыпает эту ветку шумом.

@alzadude, вам нужно отредактировать некоторые скрипты сборки grunt, чтобы он не загружал предварительно собранный электрон, отредактируйте версию package.json, чтобы она соответствовала сборке электронов, которую вы сделали локально с помощью gtk3, и, возможно, редактированием python или двумя (извините, уходит память щас). Это несложно, но когда я делаю новую сборку, у меня всегда уходит минута, потому что я всегда, кажется, забываю несколько шагов, которые сделал в прошлой предыдущей сборке.

Если @ tensor5 начинает использовать gtk3 в своем репозитории Arch-Atom, я бы посоветовал попробовать это - иначе я вернусь сюда в следующий раз, когда сделаю сборку и задокументирую изменения для вас (обычно делаю их на выходные дни)

@nikolowry, спасибо, некоторые задокументированные изменения были бы отличными :)

Я использую Fedora, поэтому я хотел бы внести изменения, основанные на этой копии Fedora:

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

Основываясь на существующей работе, я, возможно, постараюсь создать свой собственный Copr для gtk3-сборок Electron и Atom (разветвление исходных файлов спецификации rpm для включения необходимых исправлений на основе задокументированных изменений). Если, конечно, меня не опередят :)

Я пытаюсь написать для этого Gentoo ebuild, но безуспешно. Буду очень признателен, если кто-нибудь мне в этом поможет.

@ eternal-sorrow Вы уже знакомы с dev-util / electronics, ебилдом, который в настоящее время находится в официальном дереве Gentoo?

@devurandom , я сделал. Это очень старая версия электрона (0.36.12). Я модифицировал его для текущей версии (1.3.1), адаптировал все патчи, но по-прежнему возникает проблема связывания v8 (много неопределенных символов v8).

@ вечная печаль

1. Свяжитесь с [email protected] , сопровождающим этого пакета.
2. Настройте репозиторий наложения с вашим ебилдом здесь, в GH, может быть, мы сможем решить это вместе.

@ eternal-sorrow в Arch Linux мы собираем последнюю версию Electron с GTK3 , взгляните на нее.

Есть ли в этом прогресс?

@nikolowry , какую версию атома и электрона вы используете в своем atom-gtk3? Я понял, что текущие версии атома требуют электрон-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.

Дополнительная информация, chrome / google chrome dev каналы используют gtk 3, так что это только вопрос времени.

Подтверждено для Chrome 59 на https://bugs.chromium.org/p/chromium/issues/detail?id=79722#c110.

Просто вопрос времени ...

Chrome 59 вышел! : тада:

Теперь, когда вышел Chrome 59, было бы здорово увидеть предварительную версию Electron, созданную с использованием GTK3 для Linux.

Поддержка GTK3 теперь находится в стабильной версии Chromium (59), а это значит, что скоро она будет поддерживаться в Electron ! Как новичок в Linux, я не очень хорошо знаком с GTK3. Прочитав эту ветку и погуглил, я понял, что это обновление улучшит внешний вид меню, окон, диалогов и т. Д. Я думаю, что это может быть обновление, достойное блога, но хотелось бы узнать больше о том, как это изменение влияет на пользователей.

У меня есть несколько вопросов:

• Зачем вам нужна поддержка GTK3?
• Я вижу, что в этой ветке много раз упоминается "файловый диалог". Что было не так в GTK2 и как это улучшено в GTK3?
• Улучшает ли это обновление такие вещи, как производительность, совместимость и т. Д.? Или просто UI?
• Каких еще улучшений можно ожидать?
• Какие дистрибутивы Linux используют GTK (3)?

@zeke :

Зачем вам нужна поддержка GTK3? Я вижу, что в этой ветке много раз упоминается "файловый диалог".

Одно улучшение, которое меня интересует, заключается в том, что приложения Electron, работающие внутри песочницы Flatpak , теперь будут беспрепятственно использовать портал для выбора файлов на хосте. Это даже будет использовать правильный Qt, если у пользователя установлен портал Qt.

Улучшает ли это обновление такие вещи, как производительность, совместимость и т. Д.? Или просто UI?

Теоретически поддержка hidpi Gtk3 может быть актуальной, но я не знаю, как это взаимодействует с рендерингом 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 лучше интегрированы с текущими рабочими столами. Диалог File Chooser - хороший пример.

@zeke

Зачем вам нужна поддержка GTK3?

Я ценю согласованность - диалоги файлов сильно отличаются в GTK 3, темы часто немного несовместимы между версиями GTK. Мне также нравится, когда моя система минимальна, отказ Atom от GTK 2 будет означать на одну причину меньше для установки GTK 2.

Я вижу, что в этой ветке много раз упоминается "файловый диалог". Что было не так в GTK2 и как это улучшено в GTK3?

Как и выше, для меня самое главное - последовательность. Некоторые считают диалог GTK 3 второстепенным, поскольку он использует рекурсивный поиск по имени вместо инкрементного поиска в каталоге.

Каких еще улучшений можно ожидать?

В меню также следует использовать GTK вместо специальной реализации, которая, похоже, не поддерживает мнемонику и переход между соседними меню с помощью клавиш со стрелками.

Отказ от Atom GTK 2 будет означать на одну причину меньше для установки GTK 2.

Просто чтобы я понял, о чем вы здесь говорите, @jtojnar : если у вас есть более новая версия Linux, которая по умолчанию использует GTK3, то вам нужно вручную установить GTK2 для поддержки приложений, которые не обновились до GTK3? В каких еще популярных приложениях, помимо Atom (и любого другого приложения Electron), есть эта проблема?

@zeke Установка зависимостей обычно выполняется автоматически менеджером пакетов вашего дистрибутива, установка приложения GTK 3 также загрузит libgtk3 а установка приложения GTK 2 получит libgtk2 . Вы можете безопасно установить оба, просто из-за того, что на SSD мало места, я хочу избавиться от всех устаревших пакетов, которые могу.

Зачем вам нужна поддержка GTK3?

GTK3 новее и поддерживает HiDPI.
GTK2 больше не разрабатывается и не является современным.

Я вижу, что в этой ветке много раз упоминается "файловый диалог". Что было не так в GTK2 и как это улучшено в GTK3?

Не знаю об этом.

Улучшает ли это обновление такие вещи, как производительность, совместимость и т. Д.? Или просто UI?

Говорят, что GTK3 лучше использует некоторые функции процессора и оперативной памяти, но я не уверен в обратном. Хотя это было бы большое обновление пользовательского интерфейса.

Каких еще улучшений можно ожидать?

Лучшая тематическая поддержка.

Какие дистрибутивы Linux используют GTK (3)?

Все дистрибутивы имеют GTK3 в своих репозиториях.
GTK3 используется во многих основных средах рабочего стола, таких как Gnome 3, Budgie, Deepin, MATE и скоро (tm) XFCE.

Обязательным условием для этого является Chromium 59, для которого существует запрос на вытягивание для # 9946.

@zeke Главный

Я вижу, что в этой ветке много раз упоминается "файловый диалог". Что было не так в GTK2 и как это улучшено в GTK3?

GTK2 по сравнению с GTK3 можно лучше всего объяснить как более ранние версии Windows или macOS, в которых пользовательский интерфейс имел другой внешний вид (различия в макете / функциональности таких вещей, как файловые браузеры). Если вы запустите Windows 10 и увидите диалоговое окно файла, которое выглядит как Windows Vista или XP, оно будет выглядеть неуместно и, возможно, не будет иметь определенных функций / UX.

В среде рабочего стола (DE), такой как KDE, это по-прежнему создает диалог GTK3 вместо более распространенного инструментария для этого DE, Qt. Так что здесь все еще есть некоторая несогласованность, но она лучше, чем GTK2.

Вот несколько примеров в KDE с темой Breeze по умолчанию:

Диалог GTK2 с текущими приложениями Electron - GitKraken:

Диалог GTK3 - Meld:

Диалог Qt - Кейт:

Диалог Mono / .NET (?) - BundleModder - необычный для Linux, приложения Java также могут использовать необычный инструментарий:

Как видите, согласованность стилей сильно различается в разных наборах инструментов пользовательского интерфейса. Обычного пользователя может сбить с толку, почему они разные, что заставит задуматься, предназначены ли они для одной и той же цели, или разочарование из-за того, что детали навигации / презентации различаются между ними (вы можете дважды щелкнуть по GTK, в то время как Qt может быть настроен для одного щелкните по навигации по папкам) или просто посчитайте отсутствие единообразия непрофессиональным.

Gnome (DE, ориентированный на GTK) может справиться с этим лучше, чем KDE (DE, ориентированный на Qt), с единообразием между GTK3 и Qt, поскольку инструментарий Qt разработан для интеграции между платформами, обеспечивая естественное ощущение / опыт. Разработчики GTK неохотно поддерживают свой инструментарий на DE, отличных от Gnome, несмотря на то, что разработчики KDE хотят внести свой код для решения проблемы в их DE. Если пользователь не использует старые приложения, использующие GTK2 или необычные наборы инструментов, у них будет более приятный опыт.

Часто вы найдете сочетание приложений GTK и Qt, когда набор инструментов не имеет такого сильного предложения, как приложение, эквивалентное другим инструментам, для некоторых пользователей просто использование одного набора инструментов является жизнеспособным (KaOS - это дистрибутив, который обслуживает Qt5 опыт работы с дополнительными приложениями GTK, такими как Chrome). Учитывая популярность приложений Electron, избегать GTK не всегда желательно.

Зачем вам нужна поддержка GTK3?

Последовательность, диалог с файлами - это то, что больше всего привлекает меня как пользователя KDE.

Улучшает ли это обновление такие вещи, как производительность, совместимость и т. Д.? Или просто UI?
Каких еще улучшений можно ожидать?

Хотя я мало что знаю о FlatPak (изолированные приложения, не зависящие от дистрибутива, вроде Docker / контейнеров для приложений с графическим интерфейсом), я думаю, что у GTK3 есть лучшая история, чем у GTK2, включая интеграцию с DE (тематика FlatPak - еще один история для согласованности, GTK3 в FlatPak недавно получил поддержку тем, другие инструменты также должны добавить это). FlatPak, как уже упоминалось, также может облегчить проблемы с диалоговым окном файла благодаря поддержке своих порталов.

Я не слишком много знаю о GTK2 и GTK3 лично, но история HiDPI будет лучше для GTK3, я полагаю (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 не появится в Electron 1.8 с Chrome 59. В настоящее время оно блокирует сборку, поэтому нам придется подождать следующего повышения Chromium до 61 (мы пропускаем 60), прежде чем будет поддерживаться GTK3. в электрон.

Это правильно, @alexeykuzmin?

@zeke есть ли у вас приблизительная оценка того, когда произойдет удар по хрому 61? Мы хотели бы спланировать наш переход на собственные веб-компоненты ES6 в соответствии с этим выпуском. Исторически шишки случаются примерно через месяц после релиза?

@zeke
Да, у нас были проблемы с GTK3 в ветке Chromium 59.
Но мы должны перейти с GTK2 на GTK3 в предстоящем обновлении Chromium 61.

@cpoole в настоящее время у нас нет оценки того, когда Chromium 61 появится в Electron, но сейчас над этим работают https://github.com/electron/libchromiumcontent/pull/335. Наша цель - в конечном итоге идти в ногу с выпусками Chromium. Некоторые замечательные люди из Microsoft ( @cifratila , @alexeykuzmin , @alespergl , другие?)

Зачем вам нужна поддержка GTK3?

@deikatsuo Что это за браузер? Похоже, Хром и Крещение родили ребенка ...

@mdsitton прозрение 👍

Есть новости по этому поводу?

@ ziggy42 он должен быть там уже в последней версии хрома 61 (https://github.com/electron/electron/pull/10213). Я предполагаю, что это всего лишь вопрос слияния в мастере и создания релиза в какой-то момент.

Не могу дождаться, эти уродливые сборщики файлов жгут мне глаза: fire:

Разрешит ли это изменение CSS в приложениях Electron?

Итак, хром 61 слит, а будет gtk3 с ним?

Electron теперь использует GTK3 в основной ветке, будет поставляться в следующем минорном / мажорном выпуске.

@ahjolinna

Спасибо, что потратили немного здравого смысла на это обсуждение.

Возможно, вас действительно заинтересует уже упоминавшаяся KaOS.
Его поддерживает тот самый человек, который несколько лет делал Чакру великой, ИМХО.

@все

Когда был выпущен GTK + 3?

7 лет назад.

Позвольте этому немного растаять во рту.

И огромная куча программных проектов все еще сидит на 2.
Поскольку портирование доставляет удовольствие ..

На перенос кода XFCE, Mate и многие другие потребовалось 6 лет.
Другие проекты полностью перешли с GTK на Qt в течение 2.

И да: GTK + разработан GNOME, даже репо там находится.
Он - по природе и определению - разработан для GNOME и ни для чего другого.

Qt разработан для настоящей и нативной интеграции в несколько платформ.

Электрон это что?

Магазин GNOME?

Хороший.

Умное мышление.

Это то же самое, что и в императивном и функциональном программировании, а также во многих других аспектах здесь, на этой сцене: избыточное, старое, устаревшее программное обеспечение часто рассматривается как наркотик, вызывающий привыкание, что делает его одним.

А к новому, умному, инновационному программному обеспечению относятся ошибочные представления и чистое невежество.

10, 12 проектов перешли с GTK + на Qt, хотя я не знаю ни одного случая, когда произошло бы наоборот.

Пусть это снова растает у вас на языке: это означает полную переписывание всего интегрированного кода пользовательского интерфейса.
Часто глубоко вложенные.

Это означает, что они предпочитают это по сравнению с серьезным обновлением их существующего инструмента.
И все они довольны этим решением до сегодняшнего дня.

Спросите их.

Прежде чем следовать за стадом, не рассматривая альтернативы.

@ahjolinna опубликовала вам видео с одним из этих людей, VLC, Wireshark, LXQt и другие замечательные программные проекты также ранее основывались на GTK.

GTK просто используется в Chromium как привязка к Aura, и это только в Linux / freeBSD / Solaris и так далее:
Сборки Windows и macOS не содержат его.

:подмигивание:

Хотя я получаю ваши баллы @ShalokShalom , не нужно

Кнопка вилки находится вверху, кстати, не стесняйтесь.

Да, это было излишне резким.

Но я согласен. У GTK слишком много ненужных поломок, вызывающих боль, Qt был бы лучшим выбором

• ЕСЛИ QtWebEngine обеспечивает достаточный доступ к базовому экземпляру хрома
• ЕСЛИ QtWebEngine достаточно быстро отслеживает новейший Chromium

Предлагаю перенести обсуждение в более подходящее место. @ShalokShalom , как насчет того, чтобы просто открыть здесь новый выпуск и описать проблему более

VLC , Wireshark, LXQt и другие замечательные программные проекты также ранее основывались на GTK.

Это неправда. VLC использовал wxWidgets до Qt, а не GTK: https://wiki.videolan.org/WxWidgets_Interface/

Мне кажется, что люди, занимающиеся GTK, с некоторого времени признали, что они недостаточно хорошо сообщали о сбоях и версиях в серии 3.x и будут стараться в будущем усерднее с лучшей и более четкой долгосрочной стабильностью, о чем можно прочитать на https: / /blog.gtk.org/2016/09/01/versioning-and-long-term-stability-promise-in-gtk/.

Я бы также сказал, что Qt и GTK нельзя справедливо сравнивать друг с другом из-за разной истории, поддержки и целей, и, на мой взгляд, у них обоих есть плюсы и минусы в зависимости от вашей точки зрения.

Утверждение, что GTK создан для проекта GNOME и только для него, также, на мой взгляд, является несправедливым общим заявлением.

ха! я действительно не знал об этих планах. похоже, что они наконец узнали. Будем надеяться, что они начнут рассматривать любые критические изменения в CSS как настоящие критические изменения.

последнее, что я слышал, это… ммм… эксцентричный GTK 4.0 - это не GTK 4 . Итак, мы наконец достигли чего-то почти такого же хорошего, как семверь! они работают почти так же хорошо, как Qt 20 лет назад! 😁

Вскоре мы должны увидеть Electron с нативной поддержкой GTK3 по умолчанию на основе этого сообщения в твиттере :

Electron 2.0.0-beta.1 выходит с обновленными Chromium и Node.js, покупками в приложении для macOS, поддержкой GTK3 для Linux и многим другим.

да. Настоящая работа для этого была проделана авторами Chromium, и Electron получил это через обновление Chromium в Electron 2.0.0.

Кроме того, собственный код Electron получил GTK3ified в https://github.com/electron/electron/pull/11879.

Да, это было излишне резким.
Но я согласен. GTK имеет слишком много ненужных поломок, вызывающих боль, Qt
был бы лучшим выбором
ЕСЛИ QtWebEngine обеспечивает достаточный доступ к базовому экземпляру хрома
ЕСЛИ QtWebEngine достаточно быстро отслеживает новейший Chromium

Что ж, это главный вопрос. Люди думают, что для них реализовать быстрее всего, и это нормально, хотя они очень часто забывают, что фактическая реализация для его запуска сильно отличается от долгосрочного сопровождения.

С моей точки зрения, совершенно очевидно, что упомянутые вопросы можно решить.

Сравнив количество кодеров, которые действительно работают с портами GTK3, и тех, кто переносит весь свой код пользовательского интерфейса на новый инструментарий, можно увидеть, насколько поразительна разница. Думаю, я уже опубликовал об этом видео под названием «От GTK к Qt: странное путешествие».

Зачем сосредотачиваться на устаревшем программном обеспечении просто потому, что оно кажется готовым к использованию, вместо того, чтобы взламывать поддержку в Qt?

Это та догма «Я использую то, что _ кажется_ готовым», которое полностью игнорирует долгосрочные решения. Да, может показаться, что в первую очередь это требует немного больше усилий, хотя вы, ребята, наверняка извлечете выгоду из современного инструментария после его внедрения.

Также не так уж и радикально, что QtWebEngine не так быстро следует за Chrome:
Он достаточно быстрый, и Qupzilla доказывает, что с ним можно делать удивительные вещи - особенно в подходящей среде, такой как KaOS.

Вы действительно думаете, что вам нужен «больший доступ к базовому Chromium» и что «QtWebEngine недостаточно быстро следует за Chromium», поскольку Qupzilla и другое программное обеспечение доказывают, что поставляют потрясающее программное обеспечение, поддерживаемое одним единственным кодировщиком?

Вы думаете, что вам нужен более широкий доступ и более быстрое отслеживание в качестве полноценного веб-браузера в Electron? Как так?

Теперь вы сидите на этом неуклюжем программном стеке в таком большом количестве проектов, и небольшим группам удается быстро и эффективно портировать 40-60% своего глубоко вложенного кода в Qt;

То, что им не удалось сделать от GTK 2 до GTK 3, что довольно удивительно. Как сказано: для обновления основной версии большинству проектов требовалось 6-7 лет.

И почти все, кажется, игнорируют это? Это так печально, что в изначально научном сообществе продолжают распространяться столь примитивные решения.

Мир :)

@ShalokShalom , что вы имеете в виду под "устаревшим программным обеспечением"? GTK +? По какой причине вы так говорите?

Пожалуйста, прекратите этот спам Qt, это проблема с портом GTK 3. Если вы чувствуете необходимость убедить сопровождающих перейти на Qt, откройте отдельный вопрос. Я хочу получать новости о ходе реализации, а не сообщения от фанатов Qt.

Блокировка этого разговора из-за чрезмерного обсуждения не по теме.

Блокировка устраняет только симптом, но является разумным быстрым решением, поскольку переход на GTK3 завершается, и не так много осталось обсуждать тему перехода с GTK2 на GTK3.