А вот это обидно было :-)

не, я вообще без задней мысли написал. нравится — значит нравится. это твое личное дело.

Как я и предполагал.

Ну вообще да, на C++ можно такого наворотить, что уши трубочкой свернутся. На C это сделать сложнее, но только потому, что без должной дисциплины всё быстро обрушится.

по-моему, все развитие крестов состоит из попыток пофиксить грабли, выдуманные авторами крестов, но каждая итерация порождает новую связку граблей, которую они заново принимаются решать. уже давно в рекурсию впали. как на этом можно писать, или это читать, не теряя рассудок.. хз. у нас по сути C++ 98 на работе, с некоторыми разумными фичами более поздних крестов. остальное жестко режется во время обязательного code review. а если кто-то втихую наговнокодит — ну че, будет в течение всей карьеры ловить тухлые помидоры.

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

я очень благодарен тебе за развёрнутый ответ!

тут я имел ввиду что именно gtkmm вредный совет. знать C++ никогда не помешает, чтобы знать врага в лицо, так сказать

да, я понимаю, что рано или поздно понадобится. Тем более, если захочу зарабатывать на жизнь.

если не можешь найти примеров по GTK3 — бери примеры по GTK2, они практически одинаковые. отличий либо нет вообще, либо в каких-то деталях, на которые ты еще не факт кто наткнешься.

странный тулкит на самом деле. В некоторых местах я бы сделал проще, а в некоторых - дал бы волю разработчику. Ну да ладно, что имеем то имеем.

gtk-demo

о, пригодится

далее, по документации.. тебе наверное нужно что-то вроде GtkTextView.
идем в доки, и там видим такой текст

вот я дурак-то, сидел мучал gtktextbuffer и иже с ним

проходишь по ссылке, и получаешь искомое

спасибо за ссылку. Это 100% то, что мне нужно. Помечаю тему как решенную

кстати, хотел спросить 2 вещи (и i-rinat тоже)

1) это нормально что простая программа с полем и парой кнопок жрут от 3 до 5 мегабайт памяти?
2) это нормально?

Да на оба вопроса. 3-5 мегабайт даже мало. Может меряешь неправильно?

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

Пруф есть? Или ты в размерности ошибся? Такого не может быть. Вот у меня сейчас 140 threads, думаю большинство использует прямо или косвенно libc. Но памяти и близко 8ГБ не занято.

Ok, начинаем буквоедство. Linux, x86-64, glibc, память virt. Так норм?

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

Во всяком случае мне потребовались минимальные изменения моих приложений, чтобы запустить их с GTK3.

Но в итоге я перешёл на Qt. Ибо в некоторых моментах превосходит GTK по стабильности и производительности (например, у меня простой код рисования графиков дико тёк на GTK3, хотя я сделал всё возможное для освобождения памяти - текли именно кишки GTK3 при очень частой перерисовке экрана). К тому же документация к нему будет покачественнее и примеров побольше. А ещё приложения на Qt очень легко портируются на офтопик, что иногда бывает важно. GTK3 почти полностью Linux-only.

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

И вообще это очень идиотская отмазка «я ничего не знаю кроме Си». Берёшь и учишь (нет, не зубришь 10 учебников, а просто открываешь IDE/Блокнот и пишешь код). Это отличная разминка для ума - знать несколько реализаций одного и того же (несколько фреймворков, несколько языков, несколько ОС и т. д.). Позволяет мыслить не шаблонно. А не жить в своём уютном мирке.

Довольно тяжеловесен

В чём тяжеловесность выражается? В объёме библиотек? Не спорю, под офтопиком, куда Qt надо прикладывать в дистрибутив, это действительно проблема. А дистрибутив линукса без Qt - это какая-то экзотика, имхо.

Или ты про быстродействие? Не замечал, чтобы Qt был тормознее других тулкитов.

Плюсы

Оконный GUI, хорошо это или плохо, объектно-ориентирован. Соответственно, на языках с классами из коробки его реализация выглядит куда менее громоздко, чем на тех, где объекты приходится велосипедить из структур, коллбэков и указателей на функции. Соответственно, в данном случае плюсы это плюс :)

gtk2, коий считается «устаревшим, без поддержки hidpi, wayland, whatever...»

Может и считается, но в принципе можно использовать до появления предупреждений при компиляции «deprecated». эти элементы желательно обновить. Я стараюсь выбирать что-то совместимое как с 2, так и с 3. Есть, конечно, и подход типа gtk3 git master only, так чтобы получилось плохо совместимо с gtk2. Но я так и не увидел преимуществ.

либо там используется python/rust/another_weird_language.

Хороший стимул научиться читать на этих языках. Помогает быстро получить подсказку куда рыть. А вот когда пример на лиспе, ocaml или хаскеле, тогда сложнее, но если ищется не что-то об особенностях многопоточности, то, думаю, тоже будет в общих чертах понятно.

Не стоит тратить жизнь на некрофилию. Даже Линус давно перешел на QT в своих проектах. Может пора задуматься?

Насколько я понял, лично он не переходил. Его комиты с модернизацией gtk интерфейса, так чтобы оно стало совместимо с gtk3, но по-прежнему собиралось и с gtk2, мэйнтейнер просто перестал принимать, и переключился на qt.

В итоге, да, есть очень мелкие комиты и от Линуса по исправлениям qt интерфейса.

@ fluorite

Ну, gtk branch там ещё есть.

некрофилия - это всякие устаревшие языки типа Ада, фортран, алгол, etc (на некоторых из них даже сейчас пишут кстати, лол)

Ну, Ада (последний стандарт 2012) и Фортран (2010) в этом списке точно лишние. Некрофилия - это когда откапываешь компилятор, и его удаётся завести, но обновляемых проектов, использующих этот язык, уже нет.

Даже Линус давно перешел на QT в своих проектах.

и чё? плюсы уродливы. И если уж пошла речь о знаменитостях, Столлман тоже так считает. Ну и 1к страниц официальной документации к языку говорит не в его пользу.

Насчёт Линуса я уже выше писал. А вот не переживает ли Столлман за gcc, который перевели на c++?..

Основные причины, по которым бегут с GTK это плохая документация

Дааааа. Слишком кратко, неполно, практически без примеров.

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

А каких форумах?

и в рассылках

На почтовой рассылке там вообще почти никого не осталось и не отвечают. Так что даже не заметил неприветливости.

и частые сюрпризы в виде изменения API.

Ну, по крайней мере, они же API не ломают. Но когда в доке я нахожу «deprecated, исполь^W и точка», вот тогда я снова думаю, а не бросить ли и попробовать наконец-то enlightenment toolkit. Но недавно выяснил, что и там уже есть форк (и может, что-то типа gtk2/3: одни по-прежнему хотят доводить до ума, а основным - дальше, больше новых фич).

А вообще вот этим «больше не использовать, замена не нужна», а тех кто использовал мы, разработчики, лично не знаем и поэтому проблемы нет, они подчёркивают, что gtk - это их личная игрушка, а другие могут тоже пользоваться и благодарить, что хотя бы это есть. Для хобби-проектов это можно понять, но те, кто имеют права комита в гном, они же устроены в редхэтах, каноникал, так что с ними там такое?

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

В смысле резервирует (т.е. VIRT, а не RES)? По крайней мере, результат от malloc(2GB) никак не виден в мониторе ресурсов, а вот после memset'а появляется.

текли именно кишки GTK3 при очень частой перерисовке экрана

Слабо верится. Если это и был баг, то его, наверняка, исправили.

К тому же документация к нему будет покачественнее и примеров побольше.

Да, это так, к счастью перешедших, и к несчастью оставшихся.

GTK3 почти полностью Linux-only.

Не. Они поначалу позабыли о винде, но потом опомнились. Не без проблем, но и под виндой, и под маком работает.

Довольно тяжеловесен

В чём тяжеловесность выражается?

Лично для меня - кол-во зависимостей, скорость сборки самого тулкита, минимум избыточных обёрток (зачем мне QString, если есть std::string?, QThread, если с C++11 уже есть std::thread? и т.д.), средняя вложенность в стектрейсах, возможность заглянув в код тулкита, понять в общем что и как, скорость сборки приложения (C++ компиляторы сильно тормознее Сишных ввиду очевидных причин).

Но, да, выглядит Qt, признаюсь, симпатичней.

По переходу с gtk на qt для линусовой поделки для дайвинга всё разжевано на linux.conf.au. Qt — фреймворк для разработки приложений. Gtk — графическая библиотека gnome. Если ты не пишешь для gnome, помощи не жди. Gtk разрабам пофиг на тебя, и на твое приложение, и на твои багфиксы.

По переходу с gtk на qt для линусовой поделки для дайвинга всё разжевано на linux.conf.au.

Спасибо за ссылку.

Qt — фреймворк для разработки приложений. Gtk — графическая библиотека gnome. Если ты не пишешь для gnome, помощи не жди.

Рационально. С их точки зрения, не с точки зрения использующих gtk. Печально.

Но ведь гтк-шники переименовали GTK в Gtk, т.е. открестились от того, что у них GNOME Toolkit, и били себя в грудь, что у них графический toolkit. Да они даже выкинули кое-какие виджиты, т.к. они были слишком гном-специфичными, а не достаточно общеупотребительными (например, GtkRuler).

Не без проблем

This. Открываем проект в Qt Creator на нужной системе и нажимаем кнопочку «Собрать». И всё! Операции абсолютно идентичные на Windows, Linux и MacOS. Не надо ничего менять в коде, среда разработки ставится в несколько кликов с официального сайта. Можно буквально чайнику скинуть исходники проекта и прямую ссылку на инсталлятор Qt и он сможет скомпилировать проект под своей любимой ЧайникОС 10.

Причём будет работать не только UI, но и всякие плагины типа QSerialPort, браузера и т. д.

Исключения возникают только если использовать какие-то платформоспецифичные вещи (что нужно очень редко, ибо в Qt есть почти всё, что только можно захотеть), либо нестандартную систему сборки (что опять же большинству не нужно).

Для GTK это будет весьма тернистый путь и ещё не факт, что заработает. А если заработает, то что будет выглядеть нативно.

Кстати, аналогичная ситуация с поддержкой Android (и скорее всего iOS, но нужен Mac) - ставишь Android SDK и NDK, указываешь в настройках Qt Creator путь к ним. И всё. Нажимаешь «Запустить» - IDE спрашивает на каком устройстве (эмулятор или одно из подключенных в режиме отладки).

В GTK тоже есть полно обёрток над стандартными функциями - g_strlen, g_new, g_free и т. д.

QString, QThread нужны потому что они предоставляют куда больший функционал, чем стандартные примитивы. QString умеет в юникод, QThread умеет сигналы-слоты.

если с C++11 уже есть std::thread

Только вот Qt появился раньше, чем вышел C++11. Теперь что, весь фреймворк и все программы переписывать? Фреймворки переопределяют примитивы как раз для того, чтобы не ждать пока какую-нибудь фичу введут в стандарт через 10 лет, а потом переписывать весь код, чтобы использовать эту фичу. И Glib поступает точно также. И это в общем-то правильно.

STL это тоже в некотором смысле фреймворк. И Qt - конкурент STL, полноценный заменитель. Он делает то же самое, но лучше, однако и весит тяжелее + иная лицензия. В итоге для разных проектов лучше подойдут разные библиотеки.

А я вот так могу

GValue val = G_VALUE_INIT;
g_value_init(&val, G_TYPE_BOOLEAN);
g_value_set_boolean(&val, FALSE);
g_object_set_property(G_OBJECT(entry), "editable", &val);

Да, VIRT.

А каких форумах?

Ну, например, на этом. В каждой второй теме про тулкиты пишут, какой GTK+ плохой. :-)

никого не осталось и не отвечают

Входит в понятие «неприветливости». Заходишь в комнату, а там куча народу в наушниках в мониторы упёрлись. Ты им: «Привет!» А в ответ — тишина.

зачем мне QString, если есть std::string?

Так и в G-технологиях же уже давно свой GString, разве нет?

возможность заглянув в код тулкита, понять в общем что и как

Вот мне, кстати, кажется, что код с классами на C++ понять легче, чем код на C, где ООП эмулируется структурами и указателями на функции. Доля велосипедов в коде меньше.

C++ компиляторы сильно тормознее Сишных ввиду очевидных причин

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

И ещё насчёт тяжеловесности. Насколько я понимаю, если в GTK-проекте потребовалась работа с сетью, с БД, с XML - возиться с подключением соответствующих _внешних_ либ к проекту надо руками, и особенно это неприятно делать, если нужно обеспечить сборку под винду (в линуксе с этим как-то попроще). А в Qt-проекте просто подключаешь ещё несколько модулей, и файл проекта при этом выглядит идентично для всех платформ. Удобная обёртка для openGL опять-таки.

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

Я не прав?

Нажимаешь «Запустить» - IDE спрашивает на каком устройстве (эмулятор или одно из подключенных в режиме отладки).

Да ну. Вот я уже месяц-другой собираюсь это проверить. Т.е. возьму я IMAP клиент trojita и смогу в два клика скомпилировать его и запустить на андроиде?

В GTK тоже есть полно обёрток над стандартными функциями - g_strlen, g_new, g_free и т. д.

Ну, g_strlen'а - нет. А g_new/g_free можно не использовать, и недостатков при этом я не знаю. А вообще кое-какие дефйаны есть: gchar, gint.

QString умеет в юникод

А что std::string до сих пор не умеет? Вон в gtk системный utf8 в gchar (т.е. обычном чаре) сидит, только g_utf8-функции для доступа используй.

QThread умеет сигналы-слоты.

Но добавлен целый класс, а не что-нибудь потоньше, которое добавит отсутствующий функционал.

Только вот Qt появился раньше, чем вышел C++11. Теперь что, весь фреймворк и все программы переписывать?

Ну, c++11 «feels like a new language» (c), так зачем же брать из него какие-то фичи, требовать наличие c++11 компилятора, а потом оказывается, что взяли только синтаксический сахар, а сам qt по-прежнему c++98/03?

И Glib поступает точно также. И это в общем-то правильно.

Да, и у них есть g_thread. Но такой, что практически 1-в-1 pthread. Т.е. именно тонкая обёртка, которую легко убрать. А вот потоки из C11 до сих пор не реализованы в gcc. Так что, конечно, правильно, что оно реализовано в принципе. Но правильно ли QThread/g_thread было реализовывать в downstream вместо gnu расширения с++03/c99 - вот это спорно.

STL это тоже в некотором смысле фреймворк. И Qt - конкурент STL, полноценный заменитель. Он делает то же самое, но лучше, однако и весит тяжелее + иная лицензия. В итоге для разных проектов лучше подойдут разные библиотеки.

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

Входит в понятие «неприветливости». Заходишь в комнату, а там куча народу в наушниках в мониторы упёрлись. Ты им: «Привет!» А в ответ — тишина.

Да, точно.

Так и в G-технологиях же уже давно свой GString, разве нет?

В принципе - да, но им не заставляют пользоваться, например:

const gchar *
gtk_entry_get_text (GtkEntry *entry);

Вот мне, кстати, кажется, что код с классами на C++ понять легче, чем код на C, где ООП эмулируется структурами и указателями на функции. Доля велосипедов в коде меньше.

Обычный код с классами, пожалуй, да. Но код с классами на каком-нибудь «профессиональном» C++ диалекте - уже будет сложнее в понимании (без постоянной помощи clang-on-the-fly?), чем эмуляция, в которой всё более менее явно.

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

Мне уже попадалась маленькая прога, которая компилировалась минутами с пару гигабайтами израсходованной памяти. Метапрограммирование, что ли применили?

Но помимо этого экстремального примера, можно взять что угодно. Вот собирал минималистичный почтовый (IMAP/POP/NEWS) клиент на Си sylpheed: пара минут. А вот минималистичный быстрый только-IMAP клиент на C++ trojita - 19 минут (всё в один поток).

А что касается патчить: в gdb без pretty принтеров с С++ просто нечего делать. И для qt их, похоже, в Дебиане и вовсе нет. Мне пришлось в QTCreator отлаживать троиту. А и, кстати, кроме времени компиляции есть ещё важный параметр: объём debug info. Так он в С++ просто зашкаливает: 1200 MB для маленького почтовика на С++ против 39 MB в Си (du в каталоге сборки out-of-tree).

И ещё насчёт тяжеловесности.

Тут вопрос, что надо в конкретном случае. Если всё из-коробки, то можно вообще взять Моно-Сишарп. От скорости компиляции я просто обалдел (недавно попробовал собрать keepass2): оно выдало предупреждение и вывалилось. Странно, почему от предупреждения. Поковырялся и понял, что вот за эти 2-3 секунды оно действительно скомпилировало всю прогу. Хоть и не в машинный код, но всё равно просто невероятно быстро.

Т.е. это классно когда нужно что-то простенькое, которое тем не менее использует и sql, и сеть, и... Но если что-то посложнее и вдруг что-то пойдёт не так, тогда я хотел бы чтобы было ясно где искать виновника. И отдельная gui-библиотека, crypto-, network-, sql-,.. лучше. К тому же может, у них и интерфейс более менее унифицированный, так что даже заменить будет не очень сложно, чтобы протестировать.

Как решение всё-в-одном, Qt, пожалуй, даже легковесный framework. Но как gui-тулкит - тяжеленный. А Gtk и в принципе и даже потому что в нём не сидят исходники самих glib, gobject-introspection, gdkpixbuf, atk, cairo,.. - легковесный. Но, хотелось бы ещё полегче, для чего, правда, нужно совершенствование стандарта Си и gcc, и доп. работа по избавлению от велосипедов и замене их на новые стандартные реализации.

Спасибо за развёрнутый ответ.

Не интересно, в следующий раз приноси rss.

оффтоп

Freebsd 10 как desktop
Прошло два года. Как полет?

зачем мне QString, если есть std::string?

затем, что std::string — упоротый неюзабельный класс и до сих пор не умеет в юникод?

QThread, если с C++11 уже есть std::thread? и т.д.

затем, что у std::thread нет даже метода start?

Но правильно ли QThread/g_thread было реализовывать в downstream вместо gnu расширения с++03/c99 - вот это спорно.

gtk и Qt умеют в разные языки, не только в С/С++, поэтому правильно