Для простоты работы с GTK+ может посмотреть не на связку gtkmm/C++ а на Vala? В отличие от gtkmm там идёт работа с gobject напрямую, сам Vala это просто синтаксический сахар и как следствие оверхед минимален.
Сеть, файлы - glib|gio. XML - ну тут много всего, зависит от целей.
Ну конечно если C++ это преимущество для вас, то пожалуй посоветовать ничего не могу:)

Хм... Очень интересно, о Vala не знал. Спасибо. Вот только зачем его изобрели? :) На первый взгляд, реализация возможностей C++. Просто не устроила реализация некоторых концепций (к примеру шаблонов) в C++?

>сигналы реализованы через макросы, а не через шаблоны

Детали реализации не должны тебя сильно беспокоить.

Ну и всвязи с этим в последнее время начал поглядывать на Qt, плюсов много, единственное, что пока не нравится - это то, что она написана не в стиле C++

А у неё разве плохой стиль написания?

На серии библиотек gtkmm/cairomm/glibmm/cluttermm - можно написать почти любое приложение минимальными усилиями. Никакой разницы с Qt, разве что более С++ way, но зато вы правы, gnetmm нету к несчастью.

Относительно написания виджетов, то на gtkmm это делается очень просто. Но вы думаю должны понимать, что вас виджет будет работать искаропки только в самом gtkmm, вернуться назад к совместимости с gtk или еще потом сделать байндинг для какого-то другого языка может потребовать дополнительного труда. Поэтому если вам нужен виджет в своем С++ приложении, то на gtkmm все будет просто, если вы пишете библиотеку для других, то подумайте лучше о обычном gtk и создании байндинга для С++ позже.

Вторая проблема - оффтоп. Там сборка на gtkmm усложнена отсутствием pkg-config. В итоге надо написать горы параметров компилятору и линкеру.

Первого недостатка в Qt нет, ибо там вообще нет межязыкового ABI. И если делать байндинг к нестандартизированному С++, то сдесь они равны. Вторая проблема решена прекрасно с помощью qmake и QtCreator

Поговорили о недостатках, теперь о достоинствах. Gtk(mm) очень стабильное API, очень надежное и специализированно на графическом интерфейсе. Сам Gtk бинарно совместим, тоесть не нужно таскать под оффтопом с собой горы либ, достаточно одной установки на систему.

В Glib вынесен весь non-gui код. Там просто горы возможностей. В cairo вынесена вся графика, причем умеет рисовать в окно, поверхность в памяти, png, svg, pdf. Рисует cairo очень качественно. clutter я добавляю в список, ибо он полностью следует конвенции GObject, существует cluttermm. На нем можно написать приложение с действительно современным интерфейсом, если консервативность Gtk вас не устраивает. В целом рекомендовал бы держаться Gtk, так как его разрабатывали глубоко продумывая эргономичность и удобство пользователя. В нем нет мешающих производительности труда элементов

Очень часто все реализовано через сигналы. К примеру для создания потока в Qt нужно наследовать класс. Обязательно и именно так, вариантов нет. В Glibmm можно в другом потоке вызвать любой метод, статическую функцию или функцию вне класса. Многое в *mm делается также через сигнал, там где в Qt обязательное наследование. Подход с сигналом более гибкий, так как включает в себя еще и вызов не методов, или методов других классов, не связянных с обьектом-генератором сигнала.

На Gtkmm будет очень хорошо писать код, единственное в чем он уступает Qt - отстутствие IDE, которое могло быстро создавать проэкты и интегрировать вместе glib, gtk, cairo, clutter.

Vala - хороший выбор. Дело в том, что известно, что в мире Gtk бибилиотеки пишутся на С. Vala генерирует код на С. Это значит что есть два языка, на которых можна написать библиотеку для Gtk так, чтобы потом сгенерировать байндинг для чего угодно - это Vala и C. В то время как наследование виджетов на С++ даст только виджеты для С++.

Кроме отстойной документации Vala - хорошая вещь и на Vala вполне можно писать любое приложение.

О signal и slot все знают. И это никак не С++. Обростание костылями типо moc за собой ведет то, что потом надо с бубном плясать, чтобы унаследовать Qt класс не в хедере

>> сигналы реализованы через макросы, а не через шаблоны

Детали реализации не должны тебя сильно беспокоить.

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

А у неё разве плохой стиль написания?

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

На плюсах - однозначно на Qt. На пайтоне - GTK. Qt сложнее и тяжелее если приложение не велико. Да и для GTK есть Vala.

Python-Gtk вообще скорее всего будет стандартом десткопа. Я не просто говорю с новости на ЛОРе. Это то что я вижу. Если глянуть на quickly, то становится понятно к чему клонит Canonical. Они хотят сделать мощную среду разработки для Ubuntu, которая будет в основном для python и Gtk. Учитывая что все идет к доминации Ubuntu и развития идеи среди обычных пользователей что Linux is Ubuntu, Linux==Ubuntu, то python-gtk может стать де факто стандартом для десктопного приложения очень скоро. Легковесный скрипт для простого GUI, которое иногда запускает в фоне утилиты на С - идеал.

Ну про вала уже сказали. Перефразирую: его создали чтобы упростить жизнь тем, кто активно использует gobject и хочет использовать его ещё более активно, но каждый раз задумывается, а стоит ли, ведь объект или интерфейс приходится вручную долго набивать. Vala делает это за вас, на выходе получается всё тот же C код, активно завязанный на gobject. Ну и Вала всё таки проще C++. В основном это достаточно облегчённый язык, без излишеств, хорошо подходящий для гуи. Этакий С с классами:)

http://osa.samag.ru/ - тут когда-то (по-моему в первом десятке выпусков) были статьи о Qt и GTK на русском. Правда сейчас этот адрес у меня не доступен, но гуглится. Если не получится найти - у меня есть копии в архивах, но придется поискать, в каких именно номерах это было.

Ты не забывай, что Убунту это ещё и Кубунту. И не известно, что из них популярней.

Я вижу несколько компаний, в своём окружении, где используется Qt. Причём такими темпами, как сейчас Нокиа развивает Qt.. я бы не стал говорить про ГТК. Ещё один жирный минус гтк - это зоопарк сопутствующих библиотек.

> Ты не забывай, что Убунту это ещё и Кубунту. И не известно, что из них популярней.

Да ну, известно всем. Ну не надо такое уже говорить, Ubuntu - главный проект, остальные - его равноправные derivatives.

Я вижу несколько компаний, в своём окружении, где используется Qt. Причём такими темпами, как сейчас Нокиа развивает Qt.. я бы не стал говорить про ГТК.

Просто Canonical заправляет дистрибутивом. Честно говоря «главным» дистрибутивом. Значит она имеет силу управлят хожом и интструментарием для разработки под Linux. И если завтра/послезавтра появится мегоIDE для python/gtk, на котором может програмить любой как спец так и школьник, и оно сразу умеет общаться с launchpad и делать deb пакеты с зависимостями, а потом Ubuntu обьявит это флагманским и рекомендуемым инструментом разработки для десктопа. то конечно Qt будет очень грустно.

Ещё один жирный минус гтк - это зоопарк сопутствующих библиотек.

Спорили уже, хватит. Ни к чему не пришили. Итог - дело вкуса. Мне импонирует специализированность библиотеки под функции. Не хватает только IDE, такой же удачной как QtCreator, чтобы не велосипедить что-то новое каждый раз. Молимся на Canonical ))

>Ubuntu - главный проект, остальные - его равноправные derivatives.

Судя по распространению дисков и заявления Космонавта - Убунту и Кубунту являются совершенно равноправными проектами его конторы. Тем более, что у них общий репозиторий.

Просто Canonical заправляет дистрибутивом.

Ну так ничто не мешаегт ей заявить, что Qt - это главный меготулкит для десктопа:))

>а потом Ubuntu обьявит это флагманским и рекомендуемым инструментом разработки для десктопа. то конечно Qt будет очень грустно.

Проблема в том, что разработчиков мало волнует, что там объявит Убунта. Вот эслиб РедХат это объявила:))

Qt объективно лучше GTK. А GTK все используют исключительно по инерции, кому-то лень переучиваться, кто-то 10 лет назад для себя решил, что Qt несвободная, хотя она сто лет уже LGPL, а кто-то просто увидел GTK раньше Qt, говорят, цыплята принимают за мать первое, что увидят, подсунь этим людям Motif - и они будут говорить, что он единственный Ъ тулкит, а остальное - пионерские поделки, встречал я на лоре пару таких фриков. Нет смысла этих людей переубеждать, просто пожелаем, чтобы всё у них было хорошо, и не будем обижать их, им и так живётся нелегко.

Gtk лучше хотя бы тем, что поддерживает не только С++ и Python. Понятно, что для некоторых мир программирования исчерпывается С++. В этом языке далеко не все гладко, да и устаревает он уже.

Честно говоря, не пользовался gtkmm. Пишу на языках Си и Vala.

> Gtk лучше хотя бы тем, что поддерживает не только С++ и Python.

хочешь сказать, что Qt «поддерживает» только С++ и Python? :)

Я чего-то не знаю?

> Qt объективно лучше GTK. А GTK все используют исключительно по инерции

также gtk используют люди, которые принципиально пишут на С

http://en.wikipedia.org/wiki/Qt_%28framework%29#Bindings

Наверно, это очень умные и духовные люди.

Хм.. что ж, интересно. Акак их состояние? Особо интересует С#.

Ещё один аналитик с Двача?

>Qt объективно лучше GTK.
Чем?

А GTK все используют исключительно по инерции

Чушь

отя она сто лет уже LGPL

Ты даже не знаешь что и когда стало LGPL, а пытаешь сравнивать...

а кто-то просто увидел GTK раньше Qt

Чушь

встречал я на лоре пару таких фриков

... когда в зеркало смотрел.

Нет смысла этих людей переубеждать

И правда

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

Устами младенца, как говорится :)

> Акак их состояние? Особо интересует С#.

это не ко мне

В общем сыро еще. И там биндинг не столько к Qt, сколько к библиотекам KDE. На чистом Qt не знаю как получится писать или нет.

> В общем сыро еще

для С#? ну то и не удивительно

Jambi точно полноценный,

а по поводу Qyoto:

Qyoto uses SMOKE, and offers access to almost all Qt and KDE classes.

While Smoke works like a charm for Qt3 and Qt4, a modular Smoke2 has been developed which makes it easy to wrap new C++ libraries and plug them together. The result is a noticeable list of technologies available to Smoke-based bindings, as Qt, QtUiTools, QtWebkit, Qtscript, Qscintilla, Qwt, Akonadi, Plasma, KDE, KDevPlatform, KHtml, KTextEditor, Nepomuk, Okular, Phonon, Solid, Soprano

так что невнятно как то

а редхат емнип гтк больше использует

Jambi мертв

на шарпкуте даже одно приложение было, которое пиарил сам Мигель - IM клиент Synapse

>Так же хотелось бы вместо GTK что-то вроде большого кроссплатформенного фреймворка, который бы предоставлял классы для работы с сетью, файлами, XML и т. п.

Python + PyGTK + lxml + и т.п.

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

К плюсам Qt можно добавить:
1. Количество платформ, на которые Qt портирована. Написав приложение, используя только Qt, например, для Linux-x86, его можно будет очень легко портировать под все остальные платформы.
2. Развивается значительно динамичней, регулярно появляются новые возможности, из последних появившихся интересных для пользователя - кинетическая прокрутка и qt-declarative.

> И там биндинг не столько к Qt, сколько к библиотекам KDE.
Не совсем. Биндинг происходит через KDEшный Smoke, да. Однако Qyoto - для Qt, а к KDE вроде Kimono. По крайней мере легкое гугление и чтение примеров где-то тут намекает:
http://www.kdedevelopers.org/node/3696
Судя по темпам развития, оно никому не нужно.

(немного оффтопик) есть толковые бумажные книги по glib/gtk ?

На сайте gtk+ в разделе документации рекламируют такую:
http://www.amazon.com/Foundations-Development-Experts-Voice-Source/dp/1590597931
Листал для знакомства с gtk, вроде ничего.

Ну РедХат был дейстительно лидирующей компанией. До поры до времени. На Убунту слезут почти все десктопы, и уже начинают слезать сервера (кажется Википедия на Убунту Сервер). Учитывая маркетинг и динамику развития году в 2018 где-то может случиться так, что в понимании пользователей будет Linux==Ubuntu. РедХат и остыльных не вспомнят.

Пример, меня окружает коллектив людей, которые большинство времени тратят на разработку у у них нет вообще времени на настройку системы. Максимум Wallpaper поменять и софт поставить. Итог - у 70% моих друзей IT-шников Ubuntu. Она ставится 5-10 минут с флешки, все работает из коробки, поставил компиляторы, IDE, ubuntu-restricted-extras и все готово. В прагматичных кругах geekовские дистры мрут с каждым днем, интерестно, но нет времени.

Так что Python/C/C++/Java+Gtk могут быть обьявлены флагманскими очень легко. Qt - врядли, у вас иллюзия, что Ubuntu и Kubuntu хоть в какой то мере равноправные. Kubuntu немного спонсируется, до недавнего времени им денег давали только чтобы проекту их хватило на релиз. Весь форум КДЕшников сказал, что KDE там готовится ужасно, в чем я убедился поймав несколько багов. +вырвиглазый вид КДЕ ис коробки по сравнению со скринами на сайте KDE. У многих нет времени настраивать. Хотя, если честно, я ставил не Kubuntu, а просто пакет kde-full или, как-то так в Ubuntu. С другой стороны Gnome в Ubuntu сделан очень хорошо, работает очень стабильно.

Я начал с Qt, еще во времена Qt3. Хреновенькая штука. Вот Qt4 мои аплодисменты, отличная штука. Не было бы конкурента, сидел бы на нем и радовался жизни. Просто в Gtk есть архитектурные преимущества, которые задумали давно. О них писал выше. Более того, они основа DE, который стоит в Ubuntu и с выходом GNOME 3 может реально сьесть весь рынок. КДЕшники не слезут, это гарантировано, веря в карму. Но пользователи с радостью выбирают Gnome, что я вижу каждый день. Я молча им показываю Ubuntu и Kubuntu, выбор понятен. Другие дистры просто в определенный момент могут потребовать какой-то ручной настройки, поэтому многим они не подходят. Если люди переходят на Linux, то будут переходить все. IT-шники уже перешли, сейчас нужно ждать и ориентироваться на обычных пользователей. И честно говоря KDE своей маме я бы не поставил. Дед сидит уже год на Ubuntu. Поэтому я и выбираю Gtk/Clutter, потому что ожидается волна его популярности. Gnome уже обогнал KDE по популярности, как вы видели в новостях

Учитывая маркетинг и динамику развития году в 2018 где-то может случиться так, что в понимании пользователей будет Linux==Ubuntu.

По-сути, на десктопе это уже сейчас так. В последнее время, когда я ищу что-то в гугле, я вместо linux пишу ubuntu: потому что получаешь решение проблемы и, как правило, правильное решение — если установить что-то, чего нет или устаревшее в репах, то сразу ссылка на ppa, если исправление проблемы, то согласно идеологии дистрибутива и т.д. вместо linux, где каких-то невменяемые решения что-то там скомпилить, что-то собрать... пользователям нужна простота, а не задротство.

> Честно говоря, не пользовался gtkmm

Вы зря) Можете попробовать, максимально элегантная библиотека для С++, которую я видел (кроме stl). Особенно сигналы, достаточно кратко и чисто реализованы, и только средства С++.

Очень рекомендую еще попробовать java-gnome. Если на Swing не писать GUI, то java очень легковесная. Вот сейчас у меня sample по OpenGL на LWJGL. Сответственно оно без свинга, вся работа с окнами нативна внутри в LWJGL. Итог 5 МБ ОЗУ, полный FPS, и это на java, со всей ее мощностью.

Java-gnome также очень легковесный, код похож на Mono, только к счастью это не Mono. Если бы мигрировали Stetic для Java, то разарботка упростилась бы. Но так есть редактор Glade

Их вики вообще мощнейшее. Наверно даже больше чем у Gentoo, дистрибутива с книжкой. На ubuntu forums наверное сто раз находил решение проблемы. Самое интересное, что не как избавиться от глюка, давно такого не помню. Но как например поставить какой-нить выверт на сервер, это да

> Количество платформ, на которые Qt портирована. Написав приложение, используя только Qt, например, для Linux-x86, его можно будет очень легко портировать под все остальные платформы.

У Qt действительно хорошая система сборки, универсальная для разных платформ. Но количество платформ у Gtk где-то такое же, просто собирать не очень удобчно

кинетическая прокрутка

Это в Gtk 3

qt-declarative

Clutter Script. Они просто взяли и релизовали поддержку JSON в Clutter. Строим сцену в JSON, пишем код на любимом языке.

Очень рекомендую еще попробовать java-gnome.

Интересно. А насколько эти биндинги живые? Есть ли какие-нибудь косяки?

> Я молча им показываю Ubuntu и Kubuntu, выбор понятен.
Не спорю, что в GNOME есть свои привлекательные моменты, но чтоб вот так сразу определиться... что же вы им показываете? При том, что, как вы пишете, не ставили Kubuntu?

Ubuntu популярна, да, как и GNOME. Тем не менее, даже если Canonnical соорудит какой-то инструмент разработки, то очевидно лишь то, что им будут пользоваться Gtk'шники, которые его ждут. Программистам Qt нужно подавать реальную выгоду, хорошую документацию и бла-бла-бла. Потому что Qt4 есть здесь и сейчас, имеет популярность, нормально выглядит под всеми платформами и пока не чахнет. То, что в Qt4 некоторые решения нарушают чистоту языка, во-первых, поправимо в перспективе, а во-вторых, не так уж мешает грызть кактус^W^W.

На мой скромный взгляд, для школ^W новичка изучение Gtk несколько сложнее. Опытный разработчик выберет и без религиозных вбросов согласно интересам.

Поддержка 2.16, official binding. Работает отлично, косяков не нашел.

/*
 * ExamplePressMe.java
 *
 * Copyright (c) 2006-2008 Operational Dynamics Consulting Pty Ltd
 *
 * The code in this file, and the library it is a part of, are made available
 * to you by the authors under the terms of the "GNU General Public Licence,
 * version 2" See the LICENCE file for the terms governing usage and
 * redistribution.
 */
package button;

import org.gnome.gdk.Event;
import org.gnome.gtk.*;

/**
 * A simple Window with a Label and a Button in it. Demonstrates the basics of
 * initializing GTK, packing Widgets into Containers, and hooking up signals.
 * 
 * This example has been around, in one form or another, since the very
 * beginnings of java-gnome. If you're just starting out with GTK and GNOME
 * don't worry; we started here too.
 * 
 * @author Andrew Cowie
 * @since 4.0.0
 */
public class ExamplePressMe
{
    public static void main(String[] args) {
        final Window w;
        final VBox x;
        final Label l;
        final Button b;

        Gtk.init(args);
        
        w = new Window();
        x = new VBox(false, 3);
        l = new Label("Go ahead:\nMake my day");
        x.add(l);
        b = new Button("Press me!");
        x.add(b);

        b.connect(new Button.Clicked() {
            public void onClicked(Button source) {
                System.out.println("I was clicked: " + b.getLabel());
            }
        });

        w.add(x);
        w.setTitle("Hello World");
        w.showAll();

        w.connect(new Window.DeleteEvent() {
            public boolean onDeleteEvent(Widget source, Event event) {
                Gtk.mainQuit();
                return false;
            }
        });

        Gtk.main();
    }
}

> В последнее время, когда я ищу что-то в гугле, я вместо linux пишу ubuntu: потому что получаешь решение проблемы
Угу. Вот, например, проблемы с pulseaudio. Хорошие решения предлагают умники: удалить нафиг. Только когда пробовал федору и тюнил пульсаудио, узнал, что даже слово «fedora» добавляет больше релевантности выдачи. :-)

Поставил, скомпилил несколько примеров. Резюме:

1. запускается почти мгновенно (как нативный гтк)

2. памяти жрет немного.

3. тормозов на хелловорлдах не замечено :)

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

> Так же хотелось бы вместо GTK что-то вроде большого кроссплатформенного фреймворка, который бы предоставлял классы для работы с сетью, файлами, XML и т. п.

Ну если не Qt, то кроме wxWidgets мало чего остается. В линуксе является обвязкой вокруг GTK.