С небольшим отставанием от GNOME 3.22 официально анонсирован (https://mail.gnome.org/archives/gnome-announce-list/2016-Sep...) выпуск новой ветки многоплатформенного тулкита для создания графического интерфейса пользователя - GTK+ 3.22.0 (http://www.gtk.org/). В новой версии представлено (https://blog.gtk.org/2016/09/21/who-wrote-gtk-3-22/) 989 изменений, из которых 55.4% подготовлены сотрудниками компании Red Hat, 9.8% - Endless, 0.6% - Collabora, 0.4% - Canonical и 0.1% - Centricular. Выпуск 3.22 является (https://blog.gtk.org/2016/09/01/versioning-and-long-term-sta.../) последним наращивающим функциональность релизом в ветке GTK+ 3. В дальнейшем новые возможности будут развиваться в выпусках GTK+ 3.90.x, после которых будет сформирована новая стабильная ветка GTK+ 4. Корректирующие обновления для GTK+ 3.22, в которых будет сохранена совместимость на уровне API и ABI, планируется формировать как минимум три года.Код GTK+ развивается в рамках проекта GNU и распространяется под лицензией LGPL, что позволяет использовать GTK+ не только для разработки свободного ПО, но и для создания проприетарных приложений, не требуя от производителей закрытых программ выплаты роялти или покупки специальной лицензии. В состав тулкита входит полный набор виджетов, позволяющих использовать GTK+ для проектов различного уровня и размера, например, GTK+ лежит в основе десктоп-окружений GNOME и Xfce, и используется в таких продуктах, как GIMP, Firefox и OpenOffice/LibreOffice.
GTK+ спроектирован для поддержки не только C/C++, но и других языков программирования, таких как Perl и Python, что в сочетании с использованием визуального построителя интерфейса Glade (http://glade.gnome.org/) позволяет существенно упростить разработку и сократить время написания графических интерфейсов. Организация вывода в GTK+ абстрагирована от типа оконных систем, например, поставляется бэкенд, обеспечивающий возможность работы поверх дисплейного сервера Wayland, а также бэкенд, позволяющий отрисовывать вывод библиотеки GTK+ в окне web-браузера (запустив GTK-приложение на одной машине, можно открыть web-браузер на другой машине и получить доступ к интерфейсу данной программы).
Из добавленных (https://blogs.gnome.org/mclasen/2015/11/20/a-gtk-update/) в GTK+ 3.22.0 улучшений (https://developer.gnome.org/gtk3/3.22/) можно отметить:
- В бэкенд, обеспечивающий работу поверх дисплейного сервера Wayland, добавлена (https://blogs.gnome.org/carlosg/2016/08/24/wayland-%E2&.../) поддержка использовния графических планшетов Wacom в качестве устройств ввода. Для работы бэкенда теперь требуется как минимум шестая версия протокола xdg-shell;- Добавлена API GtkPadController для обработки жестов с планшетов;
- В GdkMonitor (https://developer.gnome.org/gdk3/stable/GdkMonitor.html) добавлены программные интерфейсы для получения расширенной информации о подключенных устройствах вывода, недоступной через GdkScreen;
- В GdkGLContext добавлена поддержка OpenGL ES. GtkGLArea (https://developer.gnome.org/gtk3/stable/GtkGLArea.html) теперь можно использовать как на стационарных системах с OpenGL, так и на мобильных платформах c OpenGL ES;- В GtkScrolledWindow добавлены новые свойства max-content-width и max-contentheight для ограничения максимального размера окна;
- Добавлен новый виджет GtkShortcutLabel для отображения отдельных горячих клавиш в стиле GtkShortcutWindow;
- Добавлена поддержка (https://feaneron.com/2016/07/03/css-blend-modes-in-gtk/) режимов смешивания CSS, позволяющих на лету трансформировать изображения при помощи CSS;
- Интегрирована технологий порталов Flatpak (https://www.opennet.dev/opennews/art.shtml?num=44761), предназначенных для организации контролируемого обращения к внешним ресурсам из изолированного контейнера с подтверждением операции по аналогии с динамическими межсетевыми экранами. Порталы позволяют приложению запросить доступ к таким операциям, как открытие внешнего файла, открытие URL, вывод на печать, создание скриншота, вывод уведомления, блокировка вызова хранителя экрана, получения данных о состояния сети и информации о прокси. Диалог с запросом о предоставлении доступа выводится пользвоателю автоматически при первом обращении к ограниченному ресурсу, решение о предоставлении доступа принимается пользователем. Обработчик порталов вызывается при обращении приложения к штатным функциям GTK, например, когда программа пытается выбрать файл через GtkFileChooserNative, вывести информацию на печать через GtkPrintOperation или открыть URL через gtk_show_uri.URL: https://mail.gnome.org/archives/gnome-announce-list/2016-Sep...
Новость: http://www.opennet.dev/opennews/art.shtml?num=45190
Обожаю этот тулкит. В отличие от __некоторых__ (кхм...) других тулкитов, не тормозит, настраивается через CSS и выглядит симпатично. Стандарт де-факто в мире опенсорсных гуйных приложений. А теперь хейтеры, внимание, даю команду заминусовать этот коммент!
А еще выглядит из коробки как гoвно, после каждого обновления ломается совместимость тем и вообще реализовывать планшетные интерфейсы для десктопного тулкита будут только имбицилы. Верните GTK2!
> ломается совместимость тем
> 2016
> Super-puper-GTK3-theme-by-Vasyan.rar
Ну там реально кроме Адвайты всё ломается при апдейтах.
Чтобы не ломалось - не обновляй. Никто не гарантировал совместимость тем. Активно поддерживаемых тем для GTK 3 можно сосчитать лишь по пальцам одной руки.
> по пальцам одной руки.По пальцам одной руки невнимательного фрезировщика.
чтоб не ломалось нужно изначально использовать "академический подход" а не переделывать всё каждый раз.
Там нет постоянного API. Никакой подход не поможет.
нет стабильности в API именно в результате отсутствия академического подхода
> Чтобы не ломалось - не обновляй. Никто не гарантировал совместимость тем. Активно
> поддерживаемых тем для GTK 3 можно сосчитать лишь по пальцам одной руки.Ну да, в течении нескольких лет упорно, с каждым релизом, ломать совместимость, а потом удивляться, что сторонних тем-то для GTK3 оказывается и нет, а значит и особо поддерживать или делать что-то с оглядкой на других – не нужно ... это по гнумовски.
И вообще, традиция-с:
https://mail.gnome.org/archives/gnome-shell-list/2011-June/m...
> Facilitating the unrestricted use of extensions and themes by end users
> seems contrary to the central tenets of the GNOME 3 design.Ведь все знают, что GTK используют только когда пишут приложения под GNOME!
>Верните GTK2!Из-за вяленого уже не вернуть. А так бы уже давно форк был готов.
Форкнуть и перевести на вейленд, делов то.
Qt5 уже 5 лет переводят. Всё никак не переведут. Видимо, не просто это.
Обожаю этот Qt. В отличие от __некоторых__ (кхм...) других тулкитов, не тормозит, настраивается через CSS и выглядит симпатично. Стандарт де-факто в мире опенсорсных гуйных приложений. А теперь хейтеры, внимание, даю команду заминусовать этот коммент!
> GTK+ используется в таких продуктах, как ... OpenOffice/LibreOffice.Что ты говоришь, моя радость. GUI в LO написан на vcl.
Если бы он был на GTK, то в KDE не было бы такого вырвиглазия.
Не знаю ни одного разработчика GTK, все пишут на Qt, ибо GTK это боль.
Я! Я один раз писал на gtk, точнее на gtkmm. Я думал там С++, ООП, все дела. А они там голые указатели туда сюда кидают! Пока доки не перечитаешь 10 раз, непонятно кто чем владеет.
Не знаю, когда ты что там тыкал, но ныне там умные указатели для всего.
> Не знаю, когда ты что там тыкал, но ныне там умные указатели
> для всего.У них в сишном Gobject есть счетчик ссылок. Эти умные указатели ещё один добавляют получается?
Они даже специальную функцию придумали, чтобы каким то образом модифицировать объект, только ради того, чтобы будущий владелец виджета знал, что это именно он должен этот объект удалять. Тоесть в деструкторе он проходится по всем своим объектам, проверяет, делали ли на объекте Gtk::manage, и если да, то он его удаляет. Ну или расскажите, как это работает на самом деле?
Или вот например ихний glade. Зачем гуй в хмл? Как moc звать так у всех подгорает, а glib-compile-resources дык ничо, все довольны! Только вот qt сразу вам дает объект с нужными объектами, а в гтк надо юзать Gtk::Builder::get_widget(). Ой, что это? Ссылка на указатель, да ещё и шаблонным аргументом. А всё почему? Потомучто нельзя перегружать по возвращаемому типу. А зачем им знать тип объекта который мы хотим получить? Чтобы проверить и выкинуть соответствующее исключение, как это делает add_from_file() можетбыть? Да нифига, в случае ошибки он просто зануляет указатель. Причем если я получил топ-левел виджет, то я его должен удалять, а если нет, то он сам удалится. Логично!
Ну или вот например http://stackoverflow.com/questions/23315743/gtkmm-and-gtkbui...
Я лет 7 назад, когда был неопытный, и вообще ничего не понимал, испытывал меньше баттхерта при изучении qt, чем год назад при работе с гтк.
Glib::RefPtr использует счётчик GObject, но murrayc уже планирует переход на std::shared_ptr.get_widget() и get_object() - согласен, неудачные методы. Я для них написал обёртки, чтобы возвращали указатель на вытащенный виджет/объект или кидали исключение.
https://github.com/skybon/obozrenie-cpp/blob/master/gtk/help...
Вообще gtkmm/glibmm сделан очень грамотно в плане архитектуры, но у их команды не хватает людей. Так бы давно уже на C++14 портировали и выкинули Glib::RefPtr.
> Вообще gtkmm/glibmm сделан очень грамотно в плане архитектуры, но у их команды
> не хватает людей. Так бы давно уже на C++14 портировали и
> выкинули Glib::RefPtr.Ну незнаю. Может и грамотно, но у меня было постоянное ощущение того, что они упираются в свой сишный апи и не хотят прилагать усилий чтобы сделать с++ый красивее. Вроде и на с++ пишешь, а геморрой ощущается размером с голый си.
Эх, жаль давно на гткмм писал, год назад у меня было куда больше аргументов.
Если где и есть острые углы, так это в gtkmm. А именно, те самые чистые указатели.Дело в том, что здесь мы сталкиваемся с конфликтом иерархий владения. RAII можно использовать только для контейнеров, а всеми остальными виджетами всегда управляет родитель, выполняя роль unique_ptr. Собственно, для этого и есть Gtk::manage(), который привязывает время жизни виджета к контейнеру. Я не пишу на Qt, но вижу, что там примерно так же - QWidget "держится" за родителя.
http://doc.qt.io/qt-4.8/objecttrees.html
И gtkmm, и Qt имеют иерархию в иерархии (RAII держит контейнер, контейнер - дочерние виджеты). При этом последние лучше держать в динамической памяти, ибо иначе можно огрести из-за конфликта иерархий владения - см. ссылку. Так что богомерзкий new - необходимость в любом случае вне зависимости от тулкита.
Во всём остальном - и glibmm, и gtkmm, и libsigc++ хоть и используют Glib Mainloop, но разработчику предоставляют c++-style API с исключениями, лямбдами и православной реализацией string, которая ориентирована не на байты, а на символы UTF-8.
Ты тот молодой погромист, который не осилил Qt?
> Ты тот молодой погромист, который не осилил Qt?Ему просто ехать не нужно, вот и не осилил. Ясно же, что для себя пишет (если пишет вообще).
> Пока доки не перечитаешь
> непонятно кто чем владеетА надо было вначале релизить приложение на gtkmm, а потом уже читать доки по gtkmm? Смешной такой...
> Я думал там С++, ООП, все дела.Ты хотя бы About читал к gtkmm, прежде чем начинать использовать библиотеку? gtkmm -- это обёртка над C'шными библиотеками. Или раньше не было опыта работы с обёртками?
Обёртка всегда будет требовать знакомства с низлежащей библиотекой. Просто потому что. Работа с сисколлами через libc будет требовать хотя бы примерного знания того, что такое сисколл, как он реально вызывается, что представляет из себя обёртка над сисколлом в libc, откуда берутся все эти замечательные декларации структур и тд, и тп. Для этого не обязательно быть сертифицированным разработчиком ядра, но хотя какой-нибудь обзор на пару тысяч слов, призванный ликвидировать безграмотность, прочитать стоит.
>[оверквотинг удален]
> Ты хотя бы About читал к gtkmm, прежде чем начинать использовать библиотеку?
> gtkmm -- это обёртка над C'шными библиотеками. Или раньше не было
> опыта работы с обёртками?
> Обёртка всегда будет требовать знакомства с низлежащей библиотекой. Просто потому что.
> Работа с сисколлами через libc будет требовать хотя бы примерного знания
> того, что такое сисколл, как он реально вызывается, что представляет из
> себя обёртка над сисколлом в libc, откуда берутся все эти замечательные
> декларации структур и тд, и тп. Для этого не обязательно быть
> сертифицированным разработчиком ядра, но хотя какой-нибудь обзор на пару тысяч слов,
> призванный ликвидировать безграмотность, прочитать стоит.std::thread тоже обертка над pthread и ничего, всё красиво. Так можно дойти до того, что все библиотеки это прослойки между сишным интерфейсом ядра и они должны ничем друг от друга не отличаться по степени гавености. Однако для гтк я привел пару примеров которые делают его большим гавном по сравнению с другими. Мне вот интересно, почему никто не может даже подумать о том, что разрабы этого гтк(мм) просто хреново всё продумали и получился монстр с непонятным апи? Там какието сверхчеловеки что ли сидят, которым нужно слепо доверять?
Что мешает этой обертке не юзать голые указатели и кидать исключения? В одном же месте они кидают аж три разных исключения (правда в примере зачемто их тут же обрабатывают), а в другом возвращают nullptr. А вы оправдывайте такое поведение библиотеки тем, что я якобы чтото там не почитал. Нет уж, давайте либо по существу, либо всётаки признаем что qt лучше. (хотел написать что гтк гавно, но ведь непоймут-с)
> либо всётаки признаем что qt лучше.проще признать что у кого то руки крюки и голова для шапки
> Обёртка всегда будет требовать знакомства с низлежащей библиотекой. Просто потому чтоА на ... тогда обёртка?
Не заметил никакой боли когда делал себе оболочку для mpv.
Я бы сказал почти такой же простой как вижал бейсик когда то был.Но вот отдельные личности слишком уж коряво им пользуются, например в коде Thunar я с огромным трудом сориентировался чтобы поправить совсем простые вещи, и так до конца и не сделал того что хотел ибо не нашёл места где оно реализуется.
У нас проект на GTK3, ибо используем С, а не С++. Уже несколько лет на рынке. У GTK есть свои проблемы, например, на открытый текстовый файл размером 4 Мб будет сожрано 200 Мб оперативки (версия 3.10). А с подсветкой синтаксиса будет уже 400 Мб из-за тегов. Но это решаемые дописыванием своего проблемы. Но в целом очень понятный API, удобно в использовании. Огромным минусом является разве что ленивый способ обработки ошибок в проекте, - в любой непонятной ситуации делать assert. В Си обычно принято все ошибки обрабатывать.. К примеру, человек открыл много файлов, - память почти кончилась. Он начал что-то набирать и тут assert. Хотя ошибку можно было бы обработать, выдать сообщение, и дать возможность сохранить документ.
Странно, коли так. У меня QT (правда 4 версии) пролез в систему только с одним продуктом - keepassx2.
Я перешел на GTK с qt когда вышла 4-я версия. Проблемы только с богомерской виндой были, но они обходятся, так что проблем в общем-то нет. Не понимаю, зачем qt если есть простой, понятный gtk...
> С небольшим отставанием
> выпуск новой ветки многоплатформенного тулкита для[I]"GTK-3+ upload to Debian (GTK-3+ v3.21) broke most parts of the MATE 1.14 desktop environment as currently available in Debian testing
[...]
is already scared of the 3.22 GTK+ release, luckily the last development release of the GTK+ 3-series"[/I] --https://sunweavers.net/blog/node/45[I]"Gtk is strongly related to Gnome, Gnome is strongly related to SystemD, all this is pushed onto Debian users in the usual way of “we don’t care for breaking non-XXX apps” (for XXX in Gnome, SystemD)."[I] --https://www.preining.info/blog/?p=5885
> - GTK+ 3.22.0
>...Ну, не зря некоторых гномерастами зовут. Я уж молчу про некоего П.
#>>GTK-3+ v3.21) broke most parts of the MATE 1.14
#>>strongly related to Gnome, Gnome is strongly related to SystemD> Ну, не зря некоторых гномерастами зовут. Я уж молчу про некоего П.
С другой стороны, может, россказни завистников? Вот жертвы поломок в соседней новости во всю чинят девелопменты передовых девелоперов:
"MATE 1.16 [...] Улучшена поддержка GTK+3 [...] Добавлена поддержка GTK+ 3.22 в приложениях и темах[...]"
И у Лёни в RHEL7 всё работает. Неужели, хейтеры ошибаются!? </трагедь-хоррор>
> Неужели, хейтеры ошибаются!? </трагедь-хоррор>Ровно до следующего выпуска :)
Ждём GTK++
> Интегрирована технологий порталов Flatpak, предназначенных для организации
> контролируемого обращения к внешним ресурсам из изолированного контейнера с
> подтверждением операции по аналогии с динамическими межсетевыми экранами.Здравствуй дорогой RH, я вижу твои ушки. В gtk. Это как бы уже достало.
В тулките нет штатного канваса 2d, зато есть поддерка контейнеризации. Опупительно.
> В тулките нет штатного канваса 2dЕсть Cairo. Это круче.
Несколько дней назад в Debian Stretch прилетело обновление xfce-clipman-plugin, который переписали на GTK3. Сегодня, когда надо было вытащить из истории буфера обмена одну запись, я обнаружил, что история отображается в одну строчку и сверху/снизу кнопки промотать вверх и промотать вниз, всего это окошко занимает пикселов 80 в высоту на мониторе с разрешение 1920х1080! Поймать нужную запись оказалось не так-то и легко список моментально пролистывается либо в конец, либо в начало. ГТК ни при чем, кривые разработчики апплета? ОК. Не так давно еще и xfce4-notifyd переписали на ГТК3. Теперь он игнорит тему, которую указываешь в настройках и показывает какую-то дефолтную тему с светлым фоном, на фоне которой совершенно прекрасно читаются буквы белого цвета...практически все, что переписывают на GTK3, работает хуже, чем на GTK2: не понятные глюки, совершенно тупое юзабилити...такого бардака не было ни при переходе с GTK1 на 2, ни с QT3 на QT4!p.s.
Для дебиана, оказывается, есть совершенно замечательный сайт snapshot.debian.org скачал там предыдущие версии пакетов, сделал downgrade и теперь можно работать спокойно.
GTK3 плохой, GTK3 плохой, GTK3 плохой.Повторяем за мной. GTK3 плохой.
Неправда, это темы для gtk3 плохие, а сам gtk3 -- хороший.
> GTK3 плохой, GTK3 плохой, GTK3 плохой.
> Повторяем за мной. GTK3 плохой.Осторожней, не смей говорить 3 раза "GTK3 плохой" перед зеркалом, а то GTK3 придет за тобой.
Справедливости ради, маленькое меню с кнопками прокрутки сверху и снизну - это болезнь была и в gtk2, регулярно проявляется в разных приложениях.По поповоду xfce4-notifyd, емнип, при переписывании на gtk3 у них изменился формат тем, потому что раньше оно темилось темами gtk2, а теперь gtk3, оттого и проблема с отображением.
Я на Xfce4 сижу где-то с 2012 года, действительно такой глюк бывает и с gtk2-приложениями(при этом встречается в разы реже, чем с gtk3), однако стоит просто заново открыть меню и оно открывается нормально. Вчера же я минут пять пытался и так и эдак, ан нет, все равно меню обрезано и все тут. Вообще не кажется странным, что Audiocious перешел на gtk3, а потом с воплями возвратился на gtk2. Недавно, если не ошибаюсь, в Debian хотели firefox на gtk3 перевести. Перевели, после этого вернулись обратно. LXDE, который превратился в LxQt из-за нежелания переходить на gtk3...да и вообще, gtk - это же GIMP ToolKit? Разве не показательно, что тот же GIMP на gtk2? Помнится, когда появился gtk2 все чуть ли не с радостью кинулись переписывать софт. Тогда один лишь XMMS в стороне оказался.
> это же GIMP ToolKitДавно уже как нет.
> Разве не показательно, что тот же GIMP на gtk2За GIMP лучше, конечно, знает prokoudine, но, насколько я понимаю, над GTK3 версией работа давно идёт (планы на GIMP 3.0). Но т.к. практически все крупные работы тащит на себе один Michael Natterer, времени на это пока не хватает.
Вангую что этот их новый цикл разработки отпугнёт даже самых преданных фанатов GTK и свидетелей Гнома
с тебя Ванга как с козла молока; теперь при новом цикле разработки можно быть уверенным что три года ничего не сломается, а не как раньше раз в пол года
да ничего это не значит.
гномеры как работали, так и будут работать.
просто первая циферка будет тоже километраж мотать.
А куда подевались со скролл-баров концевые кнопочки?
А почему такая узкая зона захвата рамки окна? Должна быть не меньше, чем размер курсора захвата.
бесконечная фрагментация...
Все озабочены одними планшетами. Во что вы превратили интерфейс? Эти здоровенные кнопки под палец везде! Убожество. Не знаю, куда и свалить. Сижу на XFCE пока, но и тут потихоньку GTK3 просовывают. По ходу скоро единственным нормальным интерфейсом для классического ПК/ноут останутся только тайловые оконные менеджеры.
> Сравнивает оконный менеджер с тулкитом, который рисует содержимое окна/0
Очень удобно всё на десктопе, не надо тут. Гораздо лучше,чем целиться мышкой в малюсенькие кнопочки 5×5 пикселей.
> Очень удобно всё на десктопе, не надо тут. Гораздо лучше,чем целиться мышкой
> в малюсенькие кнопочки 5×5 пикселей.Ага, особенно на ноутбуках, когда эта кнопочка пол-экрана занимает - не промажешь, но и ничего кроме кнопочки не увидишь
У тебя ноутбук размером в спичечный коробок? Любопытно-с.
> Все озабочены одними планшетами. Во что вы превратили интерфейс? Эти здоровенные кнопки
> под палец везде! Убожество. Не знаю, куда и свалить. Сижу на
> XFCE пока, но и тут потихоньку GTK3 просовывают. По ходу скоро
> единственным нормальным интерфейсом для классического ПК/ноут останутся только тайловые
> оконные менеджеры.openbox+tint2 поможет!
Никогда не понимал, зачем в 2005 так сильно навалились на улучшение Гнома. Был же KDE. Пришёл к выводу, что для людей, определяющих развитие Linux, Qt казался чужеродным, пришитым к Линуксу извне. Так или иначе, GTK конца нулевых очень сильно радовал по сравнению с GTK начала нулевых.У меня ощущение, что в наши дни Qt стал ближе к миру Линукса, чем GTK
NIH, сэр
с начало был Zenitar теперь Zenitur, не нужно писать на этом сайте лучше чеши анус.
Каким местом он стал ближе? Как была шиндузятная приблуда, так и осталась.
Короче, чтобы собрать GTK+3-3.22.30 без интроспекции, нужно регенерировать сборочные скрипты, запустив autogen.sh из архива. Те которые, идут в комплекте с GTK+3 - ваще какие-то кривые. :-\