Qt vs GTK

И нахрена мне запускать многотонный файловый менеджер, который будет грузиться с минуту, искать в нем нужный каталог, потом переименовать в нем файл и вернуться к диалоу сохранения, если я могу сэкономить себе нервы и время, переименовывая файл прямо в диалоге?

Во-во-во. Эталонный Gnome-стайл ответ:

Нинужно. Защита от дурака. Вырезать. Лишняя функциональность. UNIX-way. Комбайн. Тебе в KDE. Пользователи идиоты. Иди в винду. Для этого есть ФМ и т. д.

---

Это как с аннотациями на Evince, где функцию их добавления добавили, а функцию удаления - нет.

Так и в файловых диалогах GTK — нажимаешь кнопку создать каталог, случайно ошибаешься в его имени на одну букву и всё. Удалить его или переименовать из диалога ты больше не сможешь. Потому что ты, по мнению хиганутых — идиот и виндузятник.

А где, блджад, сортировка по типу файла?

Нет, GTK-диалоги это самое убогое что есть в GNU/Linux'ах. После него даже ужасный питонячий файловый диалог блендера воспринимается свежим глотком воздуха. Не говоря уж о нормальных файловых диалогах Qt/KDE.

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

про gовноtk
вопрос про извращённую логигу HIG'а

всё хуже и хуже.

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

Да забей, это толстый тролль. Никто в здравом уме и светлой памяти не может считать файловые диалоги в gtk «лучшими». Разве что HIG'анутые или какие-нибудь циссексуалы/гендерквиры.

Вот кстати. В шинде диалогами сохранения\открытия файлов занимается explorer. Что мешает в линуксе выработать стандарт интерфейсов функций для файлового менеджера, которые будут вызывать файловый диалог? Тогда даже контекстное меню для файлов будет доступно со всеми расширениями (типа создать архив\dropbox etc)

Что мешает в линуксе выработать стандарт интерфейсов функций для файлового менеджера, которые будут вызывать файловый диалог?

Что помешало GNOME Foundition взять Qt Creator и допилить его для своих нужд, а не собирать бабло на какой-то двухкнопочный IDE-Builder?

Фатальный недостаток всем мешает. И религия.

Так что никогда не будет актуального и адекватного интерфейсного стандарта, которому бы подчинялись как Gnome, так и KDE. Как Qt, так и GTK. Все DE и тулкиты отдаляются друг от друга. GTK3+ программы с их Client-Side Decoration адекватно работают только в Gnome 3. KDE со своими плазмоидами, стеклом, металлом и прочим говноXygen'ом нормально выглядят только в KDE.

Где, мать вашу, унификация? В Gnome 2 и KDE 3 она была. Вы могли использовать десктоп от Gnome, а панель и меню от KDE. Но эти DE в прошлом, их фактически убили.

Солидарен в этом мнении с KRoN73: Привет из 2009 года (комментарий)

Сейчас всё идёт к тому, что будут созданы Gnome OS и KDE OS. Да может и к лучшему. Надоела откровенно хреновая мимикрия одних тулкитов под другие.

Сказал человек не понимающий что такое moc.

В gtkmm без moc работает все. А еще moc не умеет в множественное наследование и шаблоны.

И ни кто тебя не обязывает пользоваться Qt-контейнерами, хочешь используй C++

Многие методы возвращают Qt-контейнеры

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

Тупо виджеты они теперь тоже на qml делают.

Спасибо гномодевелоперам за Кьют.

Месье в курсе, что кроме GPL/LGPL редакций, существуют еще платные версии с дополнительными проприетарными модулями (Qt Purchasing, Qt Charts, Qt Quick Enterprise Controls и т.д.) вместе с разными вкусными плюшками (Qt Quick Enterprise Designer, Qt Quick Enterprise Profiler), которые полностью отсутствуют в урезанной опенсорсной редакции? Если уж это не полупроприетарщина, то что тогда вообще полупроприетарщина?

Ну так то и линукс платный бывает (RHEL, SLES и так далее) и что теперь все дистрибутивы линукс полупротиетарщина? Чушь какую-то пишешь. Qt под LGPL распространяется, выучи уже это наизусть. А то что он распространяется и под другими лицензиями - а тебе то что? Разработчик же должен что-то зарабатывать, результат работы школьников и энтузиастов мы видим по качеству многих других проектов.

Что помешало GNOME Foundition взять Qt Creator и допилить его для своих нужд

Вы, видимо, хорошо разбираетесь в кутикреаторе (в том, как он сделан) и ещё лучше в гноме.

какой-то двухкнопочный IDE-Builder?

Ну да, ведь в IDE обязательно должна быть куча тулбаров, тултипов, тайлов какой-нибудь особо сложной мозаики и прочего сверхнужного говна.
Кстати, до билдера у гнома была Anjuta. Почему вместо неё появился билдер — читайте у разработчика билдера.

Чем оно лучше Xfc?

Т.е. фактически тот же самый многотонный файловый менеджер должен быть запущен как часть тулкита? В составе всё того же текстового редактора.

И что это за такое прогрессивное графическое окружение, где файловый менеджер запускается каждый раз по новой при операции с файлом?

Никто в здравом уме и светлой памяти не может считать файловые диалоги в gtk «лучшими»

Лучшими относительно чего? Он лучше как минимум диалогов Qt и kdelibs наличием поля ввода пути с нормальным автодополнением. Да и вообще он почти весь с клавы рулится. В Qt-шном, в принципе, тоже можно вбить путь в поле имени файла, и даже дополнять, но черезжопненько как-то, да и в целом диалог создаёт впечатление мышевозной вантузятной дряни; GTK-шный поприятнее, да и покрасивше (кроме ряда приложений, в т. ч. гномощелевских, в которых его расколбасило с недавних пор почему-то).

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

Сортировка по типу файла? В файловых диаогах gtk есть фильтр по типу, а сортировка должна быть в ФМ. Жаль что нету.

Можно конечно добавить все возможные и невозможные функции в программу, а лучше сразу в тулкит или фреймворк. И получить на выходе kopete, уникальный im-месенджер с системными требованиями примерно как у win vista, только места на диске занимает на порядок меньше. Или очередной amarok, занимающий гиг оперативы и настолько крутой и навороченый, что убогим gkt'шникам не дано с ходу осилить добавление папки музыки в плейлист. Уверен, что файловый менеджер, пара-тройка СУБД и интернет браузер обязательно должны входить в штатный комплект медиаплеера.

kopete, уникальный im-месенджер с системными требованиями примерно как у win vista

враньё

amarok, занимающий гиг оперативы

ещё раз враньё

убогим gkt'шникам не дано с ходу осилить добавление папки музыки в плейлист

да, это реально скудоумие

я запускал эти поделия и специаьно замерял. копит ~380 М, амарок стартовал с ~700 и за 15 минут утёк до 1,2 Г. Может быть кто то не умеет их готовить, не знаю кто и как собирал те пакеты. Но даже если этих монстров собрать правильно, будут ли они лёгкими и понятными?

копит ~380 М, амарок стартовал с ~700 и за 15 минут утёк до 1,2 Г

подсказать адрес нарколога?

https://www.kde.org/ ?

Специально ради вас поставлю этих мамонтов через gprs и выложу скрины.

У меня отчего-то все Qt-приложения очень сильно тормозят при пробросе иксов через интернеты, в то время как GTK2/GTK3 летает как на локалхосте.

ой как мало гойтекашников. это таки притеснение!

и да, как много кьютешников в теме, не осиливших найти гтк-кнопку «проголосовать» и спешно оставляющих свой голос в треде.

То есть Qt? )

GTK следует рассматривать вместе с Glib и GObject, потому что Qt это фреймворк, а не просто графический тулкит. А в этих библиотеках есть свои реализации списков, динамических массивов, строковых функций (по причине того, что в Си стандартная библиотека куда скуднее). Так что ничем GTK в этом плане от Qt не отличается. И да, Glib с GObject сообщество вполне нормально поддерживает, извращаться начали как раз с графическим тулкитом.

http://s008.radikal.ru/i303/1503/9e/1290619c34a9.png

Старт не быстрый, но приемлимо. После старта потребление ~80 M, в течении 15-20 сек амарок что то делает (это видно по графику процессора на коньках, вся шкала - 120сек) и раздувается до значений на скрине. Из 3 обнаруженных способов добавить папку в плейлист 2 не работают. За 1,5 часа проигрывания музыки паять утекла до 625 М. Согласен, это не гиг+ , но надо удариться головой чтобы считать это нормальным.

Для сравнения в мониторе строчкой ниже clementine с сутками аптайма.

Копит оказался вполне скромным: 25М памяти приложения и 110М разделяемой памяти при старте. Тестировать его не собираюсь, т.к. он конфликтует с psi из за порта.

Qt. Как с позиции пользователя, так и с позиции не ахти какого, но разработчика-велосипедиста.

Потому что велосипедить на Gtk - страшно

в течении 15-20 сек амарок что то делает (это видно по графику процессора на коньках, вся шкала - 120сек) и раздувается до значений на скрине

сканирует библиотеку, наверное

Из 3 обнаруженных способов добавить папку в плейлист 2 не работают. За 1,5 часа проигрывания музыки паять утекла до 625 М

надо удариться головой чтобы считать это нормальным

а что за дистрибутив?

Месье в курсе, что кроме GPL/LGPL редакций, существуют еще платные версии

В курсе. Отношусь спокойно. Разработчикам Qt тоже кушать надо. LGPLной версии вменяемому разработчику за глаза хватит.

Тенденции таковы, что в будущем будет только усиливаться разделение на платную полнофункциональную версию и бесплатный кастрированный GPL/LGPL огрызок

Я видел обратную тенденцию. Я помню Qt3, у которой была крайне невнятная схема лицнзирования. А потом сделали LGPL под все платформы.

бесплатный кастрированный GPL/LGPL огрызок, пригодный только для написания хелловорлдов

Всё-таки тролль. Вопросов больше нет.

LGPLной версии вменяемому разработчику за глаза хватит.

+1 (я про Qt 5.x без всяких там дополнительных платных модулей-шмодулей)

Когда говорят GTK+, подразумевают весь стек библиотек на основе Glib/Gobject Introspection.

Ну вот, уже уточнения пошли ;)

А в «стеке библиотек на основе Glib/Gobject Introspection» есть что-нибудь кроссплатформенное для работы с сетевыми протоколами? С XML? (Ну с XML-то есть наверняка.) С базами данных? (Саму GTK+ я слегка ковырял на предмет внесения патчей в чужой код, с остальным не сталкивался.)

Если всё это действительно есть и в большом проекте, где всё это понадобится, не надо подключать десяток чужеродных библиотек и писать 100500 преобразований типов строк и контейнеров - хорошо. Можно будет сравнить.

Ах да, чуть не забыл. У Qt своя собственная система сборки есть, хотя некоторые всё равно cmake предпочитают. В принципе, это не киллер-фича, можно обойтись без неё, просто с родной системой телодвижений чуть поменьше нужно. Хотя cmake юниксвейнее :)

То, что лучше подходит

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

Офлайновая адресная книжка. XML нужен, чтобы импортировать некоторые форматы, сеть - чтобы синхронизироваться при необходимости со всякими гуглами (если пользователь это явно запросит). Наконец, для быстрого внутреннего хранения можно заюзать sqlite, чтобы не парсить всякий раз тот же XML при запуске, поэтому желательна работа с БД.

В Qt всё это есть. А как насчёт стека библиотек на основе Glib/Gobject Introspection?

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

GTK2.

Но «Пусть расцветают сто цветов», конечно же. Унификация не нужна. Унификация противоречит Свободе.

Где WPF?

Некоммерческий проект «LINUX.ORG.RU: Русская информация об ОС Linux»

дебиан 7 амд64, Amarok Версия 2.5-GIT Использует KDE 4.8.4 (4.8.4)

И не надо рассказывать про устаревшую глючную версию, глюки могли поправить, но легче и быстрее он стать не мог. Ещё ни один ДЕ и медиаплеер в новой версии не становился легче и быстрее. Только если его форкали и чистили.

И не надо рассказывать про устаревшую глючную версию

надо, Федя

легче и быстрее он стать не мог

тем не менее, он стал, Амарок в те времена вообще был очень глючным и тормозным

Унификация противоречит Хаосу. А свобода это совершенно другое.

ну так покажите свой, лёгкий и безглючный

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

Тем не менее, большинство основополагающего софта либо напрямую используют GTK (GIMP, Inkscape, Ardour), либо через слой абстракции (тот же FF, Eclipse, Audacity), GTK софт субъективно удобнее и юзабельнее Qt аналогов (это даже некоторые проголосовавшие за Qt признают), а GNOME/GTK по-прежнему официальные проекты GNU, одобренные лично Столлманом.

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

В любом случае, решать конечно будут разработчики, а не лоровские оналитеги.

Ну так то и линукс платный бывает (RHEL, SLES и так далее) и что теперь все дистрибутивы линукс полупротиетарщина?

Ред хат оказывает коммерческую поддержку. Дигия также оказывает поддержку, но вдобавок продает коммерческие модули и тулзы, недоступные в свободной GPL/LGPL версии. Почувствуй разницу.

Стало быть культи - это комбинация свободных и несвободных модулей. То есть полупроприетарное ПО. Ну или полусвободное, кому как больше нравится.

Если ты под Qt имеешь в виду именно урезанный GPL/LGPL огрызок, а не полнофункциональную тырпрайз редакцию, то так и надо говорить - «урезанный GPL/LGPL огрызок». Или более политкорректно «Community Edition». Нужно называть вещи своими именами.

потому что веб-клиент доступен из любой системы и ничего не надо конпелять.

показываю

А в этих библиотеках есть свои реализации списков, динамических массивов, строковых функций (по причине того, что в Си стандартная библиотека куда скуднее).

Да, с контейнерами ты конечно прав, в С просто по-другому не сделать. Но. Тот же gtkmm использует православные std::string, std::vector и т.д. Конечно внутри все равно используются GLib контейнеры, но в Qt даже такого нет - там все публичное API работает только со своими велосипедами.

Другой пример - для работы с сигналами gtkmm использует уже существующую libsigc++, а в Qt - внешние костыли moc и уродские расширения C++. Макросы SIGNAL/SLOT это вообще адское позорище, только в Qt 5 connect несколько довели до ума.

Если же взять сам gtk, то он опирается на существующие cairo, pango, gettext, в то время как в Qt все это накостыляли с нуля, вдобавок запилив кривой и убогий аналог STL и частично буста.

Так что ничем GTK в этом плане от Qt не отличается.

Наоборот - по количеству заново изобретенных велосипедов Qt далеко впереди GTK, здесь даже спорить не о чем.

LGPLной версии вменяемому разработчику за глаза хватит.

Где-то я это уже слышал... Ах да, 640 кб хватит всем.

Если ты под Qt имеешь в виду именно урезанный GPL/LGPL огрызок, а не полнофункциональную тырпрайз редакцию, то так и надо говорить - «урезанный GPL/LGPL огрызок».

Ты имеешь право называть Qt как тебе угодно, от этого никому не холодно и не жарко. Важно чтобы ты понимал что он под LGPL и не вводил никого в заблуждение.

Что помешало GNOME Foundition взять Qt Creator

Что помешало Qt разрабам взять любой текстовый редактор или IDE и допилить его для своих нужд, а не пилить какой-то двухкнопочный (долгое время) QtCreator

Куча паники ниочем. Я не пользуюсь ни KDE, ни Gnome, ни Unity, ни Mate, ни Cinnamon, ни Pantheon. И ничего, не делаю из этого трагедии.

Потому что 2015й год на дворе. Для разработчика вполне можно что-то настроить вроде каких-то WM или даже вышеназваных DE. Он все равно пялится целый день в какую-то IntelliJ IDEA.

А вот пользователи все равно сидят в браузере или в игре целый день. А то и на планшете или телефоне. Там проблемы десктопа сугубо побоку. Скажете, а как же работу работать офисному планктому? Так там браузер тоже обычно и все. Плюс офис. Для тех кто вовремя не сбежал на Google Doc существует единственный реальный офис - Microsoft Office который к линуксу никаким боком.