Gtk vs. Qt: драки не будет
Материал из Wiki.crossplatform.ru
Автор: Арсений Чеботарев "Комиздат" 3 марта 2005 г
Стоило только мне написать об Qt как об одной из основополагающих библиотек в мире открытых систем, как тут же вламываются ко мне озверевшие линуксоиды и начинают доказывать, что самая основополагающая — это Gtk. Спокойно, господа, опустите ваши колы с стволы. Я и не отказываюсь — есть такая буква, точнее — целых три.
Содержание |
[править] Происхождение
В чем разница между Qt и Gtk и что сразу бросается в глаза — так это их происхождение. В мире открытых систем существует два источника происхождения софта.
Первый: что-то было разработано одним человеком (двумя, тремя) для себя или для своей работы, а в дальнейшем, в силу корпоративной политики, стало достоянием общественности — но, те не менее, продолжает строго разрабатываться по корпоративному плану, с учетом пожеланий пользователей продукта. На сегодня таким образом рождаются самые интересные, стабильные, "сбитые" и хорошо документированные детища.
Второй путь — это когда кто-то что-то писал-недописал, выложил, потом пришло еще двое, что-то переделали, потом еще сто пятьдесят человек внесло свою лепту (лепта — монета, вставляемая известно куда; соответствует нашим "пяти копейкам"). Потом еще какие-то люди таскали-портировали, документировали… Пока, наконец, не пришли коммерсанты и не начали лицензировать. Залицензировали версию 1.0.5, после чего вышла "свободная" 2.6.3 — и с тех пор никто толком не знает, где у этого бегемота нос, а где — хвост. Апологеты такого "зоопарка" аргументируют ситуацию примерно так: "Вам нужен нос? Вот он — и не нужно спрашивать, где хвост. Достаточно знать, что он тоже есть".
К первому разряду программ относятся, например, MySQL, PHP, Python, Qt и сам Linux, изменения в ядро которого вносит сам товарищ Торвальдс.
Но и во второй группе тоже немало программ, таких как Gtk или PostgresQL. Эти программы отличаются обширными экстенсивными интерфейсами, которые писались кучей народа — и, судя по всему, не предназначены для освоения одним человеком. По подобию вавилонского столпотворения это напоминает мне только интерфейсы Java. Оно и понятно — при создании Java применяются многие из "группен-секс"-технологий разработки, которые используются в интернете и мире GNU.
Чтобы как-то продемонстрировать сказанное, напомню историю создания Gtk (сокращенно, с сайта gtk.org).
[править] История Gtk
Разработку Gtk начал Питер Маттис (Peter Matthis), ему помогали Спенсер Кимбэл (Spencer Kimball) и Джош Макдональд (Josh Macdonald).
Мариус Вольмер (Marius Vollmer) навел на мысль, как GTK+ должен работать с различными языками программирования.
Ларс Хамман (Lars Hamann) и Стефан Джеске (Stefan Jeske) добавили все возможности в основные элементы управления.
Карстен Хайзлер (Carsten Haitzler) разработал и реализовал первую поддержку тем.
Шоун Амундсон (Shawn Amundson) занимался менеджментом релизов GTK+-1.0 и GTK+-1.2.
Позже, Хавок Пеннингтон (Havoc Pennington) создал элемент управления GtkTextView, основанный на текстовом поле Tk.
Эллиот Ли (Elliot Lee) и Алекс Ларсон (Alex Larsson) написали linux-fb бек’энд (Gtk через фрэймбуфер).
Эрвонн Ченед (Erwann Chenede) добавил многопоточность в GDK и GTK+.
Падрейдж О'браен (Padraig O'Briain) и Билл Ханеман (Bill Haneman) написали ATK и исправили GTK+ для поддержки accesibility (интерфейс для инвалидов).
Ханс Брюер (Hans Breuer) продолжает "контрибьютить" огромные части полезной работы для порта Win32 GTK+ (убитое время — "Майкрософт" не оценит).
Мюррей Камминг (Murray Cumming) и Джеймс Хестридж (James Henstridge) следят за корректной поддержкой различных языков.
Abigail Brady, Sivaraj Doddannan, Dov Grobgeld, Karl Koehler, Theppitak Karoonboonyanan, Noah Levitt, Eric Mader, Roozbeh Pournader и Changwoo Ryu — это лишь некоторые из тех, кто приложился к Pango...
Что является характерным, так это метод, которым развивается Gtk. Основой для тех или иных работ в данном случае не может служить ни распоряжение начальника, ни материальный стимул. Поэтому в качестве "производственного плана" выступают "направляющие" — Guidelines. По мере того, как очередной кто-то захочет прославиться в мире GNU, он может выполнить любую приглянувшуюся ему часть кодирования. Фактически, при этом нет никаких гарантий, что возможность будет когда-нибудь реализована. Например, настраиваемые панели управления или индикатор раскладок клавиатуры могут ждать своей очереди еще очень долго. (Зато реализованы такие "супервозможности", как масштабирование иконок на рабочем столе — ну, что тут можно сказать...)
Аналогичным же образом — то есть в зависимости от хорошего настроения контрибьютеров и мэйнтейнеров — устраняются ошибки и выполняются пожелания пользователей.
[править] Структура Gtk
Если я утомил вас "историей", это хорошо — вы должны были почувствовать, что такое разработка в джунглях. Освоение Gtk приводит к таким же ощущениям. Впрочем, не будем забегать наперед.
В дополнение приведу еще пару фактов. Изначальный проект назывался GIMP, что значит GNU Image Manipulation Programm (то есть что-то типа Photoshop 3), откуда, собственно, и растут ноги Gtk. На основе того же Gtk построен и ГНОМ — оболочка GNOME (GNU Network Object Model Environment). Самая основная либа для рисования — так называемый GDK (GIMP Drawing Kit), который изначально был "эксплойтером" XLib, а теперь под настроениеможет использовать и Windows GDK.
Вот такая вот иерархия. Графической библиотекой GDK я и сам не брезгую попользоваться, о чем расскажу в одной из статей. Но следует ли из этого, что Gtk — панацея от геморроя? Ответ неизвестен.
Сам Gtk+ (с плюсом) состоит из трех частей.
Glib. Представляет собой низкоуровневый остов всего Gtk+ и GNOME; в этой библиотеке описаны основные структуры, сделаны усилия по отделению Gtk от операционной системы, а также реализованы такие "базисы", как цикл сообщений, потоки, динамическая загрузка модулей и система runtime-вызовов между объектами. Фактически это целая MS Windows 3.11 ("ось" без собственных файловых систем и т.п.), изначально написанная под X-Windows. Pango. Компонент, рисующий шрифты. Конечно же, тема это важная, спорить бесполезно, но я бы уже договорился раз и навсегда, как их рисовать, чтобы ни одни "инди-попс" не занимался альтернативными начертаниями, хинтингом и антиалиасингом. Этот вопрос на 99% на совести Adobe — откройте код, изверги.
Впрочем, создатели Gtk делают вид, что Pango и есть такая "земля обетованная". Поддержка интернациональных написаний также предусмотрена и гарантируется. ATK. Набор средств для пользователей, имеющих различные недостатки. В этом наборе: "читатель экрана", увеличительная "лупа", а также поддержка нестандартных устройств ввода. Ко всему этому, Gtk имеет привязки (bindings) к 28-ми языкам программирования, начиная от "блатного квадрата" C++/Java/Perl/Python и заканчивая такими экзотическими наречиями, как Erlang и Hasskell (кстати, кто напишет хорошую статью по Hasskell? — у меня руки не доходят). Я уверен, что мало людей знают хотя бы половину этих языков — зато неимоверная работа проделана.
С другой стороны, можно понять тягу "малых языковых народов" к Gtk — эта библиотека прикроет любые пробелы собственных библиотек. Так что, можно сказать, неплохой шанс — правда, кому и зачем он дан? Ведь потом показывают программы на каком-то ObjectXLAM и говорят: вот, мол, как красиво! — хотя на самом деле это Gtk-bind, а сам язык страшен и нуден, как три подвала НКВД.
Поскольку Gtk занимается, в основном, пользовательским интерфейсом, то существует несколько инструментов, позволяющих создавать этот интерфейс визуально. Вероятно, главное такое средство — редактор Glade. Но, как это принято, все заканчивается обычным текстом на том же C — а не ресурсами времени выполнения, как кое-кто мог подумать. Точнее, Glade может генерировать исходники на C, C++ и Ada, а также работать в gladelib-режиме, когда данные формы сохраняются в виде XML, из которого тексты генерируются на этапе сборки. Второй метод обычно используется для больших проектов.
[править] Разработка приложений: уровень абстракции
Что еще отличает Gtk от Qt, так это среда разработки самой библиотеки и целевая среда разработки. Qt написан на C++ и предназначен для разработчиков на этом языке.
Если говорить об ООП и графическом интерфейсе, то объектное программирование, контроль типов в духе C++ и встроенный в язык полиморфизм являются идеальным примером применения теории на практике. Вполне естественно, что современные системы программирования идут "немного дальше" классического C++, дополняя объекты информацией времени выполнения для дополнительных возможностей контроля типов.
Gtk написан на "чистом" С — то есть совершенно без использования классов C++, шаблонов и т.д. Тем не менее, Gtk — объектно-ориентированная система, основанная на вызовах "методов", обратных вызовах, генерации сигналов и регистрации их обработчиков. Этот подход не нов — так же написана, например, и сама Windows, по крайней мере 3.11 (опять это сравнение), и такие объектные системы, как PalmOS, MySQL и Plan9. Во всех перечисленных системах есть объекты, очереди сообщений и средства регистрации реакций на них — но реализовано это не механизмами C++, а в независимой от языка манере.
Как следствие использования C, Gtk — в некоторой мере более оптимизированная, а также более портабельная библиотека, поскольку сообщения, сгенерированные одним языком, могут быть обработаны в процедуре, написанной на другом. С другой стороны, использование стандартных механизмов C++ в Qt дает более мощный высокоуровневый базис для разработки приложений — ведь не зря же эти "классы Бьярна" получили такое распространение.
Затрудняюсь даже сказать, что лучше,— оба метода нашли широкое применение. Один из них чуть быстрее — но зато и более сложен в освоении и использовании. Другой "жирноват" — зато с ним легче управиться.
Единственное, что можно просто констатировать, так это тенденцию, суть которой образно можно свести к следующему: "быстрая разработка превыше оптимизации кода". С этой точки зрения Qt имеет большое преимущество.
[править] Уровень детализации
Как следствие применения "низкоуровневого" C (хоть это и не очевидно), Gtk имеет значительно более низкоуровневый контроль над всеми деталями интерфейса, в особенности это касается графических параметров. Так что педанты, любящие "ковыряться" в интерфейсе пользователя и строить всякого рода замысловатые элементы, типа "нажми, поверни и выбери", найдут в Gtk больше поводов для самореализации.
Мое скромное мнение в этом вопросе таково: с точки зрения приоритетов разработчика создание вычурных интерфейсов должно стоять на самом последнем месте. Безусловно, некоторые нововведения допустимы, и даже необходимы,— но, будь я Верховным Жрецом Исходного Кода, я бы наложил табу: "не больше одного новшества в интерфейсе пользователя в год". При том одного на всех разработчиков!
Как правило, эти нововведения затрудняют работу пользователя, а не наоборот. Я всегда оставался "обычным пользователем", так что и сейчас представляю их интересы — и потому знаю, что говорю.
Уровень детализации на уровне API не обозначает, что основанный на Gtk GNOME лучше проработан, чем основанный на Qt KDE. Скорее наоборот, почему я всегда использую KDE. С виду привлекательный GNOME до сих пор не "разжился" даже собственным индикатором раскладки клавиатуры. Не говоря уже о том, что под GNOME мне случалось наблюдать и куда более неприятные странности. Например, в последней версии Fedora Core 3 GNOME в одночасье перестал печатать в консоли — самое занятное, что обнаружить причину так и не удалось. Естественно, приложив достаточно усилий, можно было бы и разобраться — но я был бы рад, если бы этим занимались люди в рамках "респонсибилити".
Нужно сказать и о детализации в архитектуре. Причем речь идет не только о функциях и способах описания элементов управления, а и о модульности самой библиотеки. Gtk, как уже было сказано, состоит из доброй дюжины надстроек и сервисов, таких как GLib, GdkPixbuf, GDK, GObject, Pango и т.д. Конечно, для создания простой формы вы не обязаны знать все подробности, но все же такая "слоенка" вызывает некоторые опасения насчет стабильности и согласованного взаимодействия отдельных частей. Хотя вынужден признать, что фактами такие опасения пока не подтверждаются.
С другой стороны, в версии четыре Qt стала значительно более "фрактальной" по сравнению с 3.3.3, так что в некотором смысле обе библиотеки идут встречными курсами. Тем не менее, вы — как разработчик — при выполнении миссии "познать Gtk" столкнетесь со значительно более суровым вызовом, чем, скажем, в задании "изучить Qt".
Кстати, коль уж зашла речь о познании, вот вам последний убийственный аргумент в пользу Qt — документация. Кто видел когда-нибудь документацию Trolltech, тот согласится, что это образец полноты и ясности изложения. С другой стороны — попробуйте-ка просто найти документацию по Gtk...
О’кей, вот она: /usr/share/gtk-doc (почему же не doc/gtk?). Собственно, документация достаточно полная — однако состоит из многих частей, как и сама библиотека. И в конце концов вы, конечно же, можете получить всю нужную вам информацию — но сколько килоджоулей на это уйдет, не берусь предсказать.
Неопровержимый факт: Hello World. Я не буду тут что-то особо расписывать — все и так ясно: инициализация, создание окна, метки, переподчинение последней и отображение, вход в цикл сообщений. Компилируются Gtk-приложения (а также GDK и так далее) с флагами, поставляемыми утилитой pkg-config:
gcc `pkg-config —cflags —libs gtk+-2.0` hello.c -o hello
#include <GTK gtk.h> int main(int argc,char **argv) { GtkWidget *window; GtkWidget *label; gtk_init(&argc, &argv); window = gtk_window_new(GTK_WINDOW_TOPLEVEL); label = gtk_label_new("Hello, World!"); gtk_container_add (GTK_CONTAINER (window), label); gtk_widget_show(label); gtk_widget_show(window); gtk_main(); return(0); }
Почему GNOME?Немного остановимся на вопросе, почему компания Red Hat приняла решение использовать GNOME в качестве оболочки по умолчанию.
Вопрос довольно сложный: Красные Шапки являются коммерческой организацией, которая внедряет бесплатный Linux в мир бизнеса. Типичный покупатель Red Hat — это руководитель коммерческой компании, желающий использовать и разрабатывать коммерческие приложения, но не желающий платить лицензионные отчисления в какой-либо форме, кроме "стоимости носителей" и небольшого ревеню создателям дистрибутива, в основном за поддержку. А поскольку коммерческое использование уже выходит за те рамки, до которых простирается "Free License" от Trolltech, то RH правильно делает, что не распространяет Qt там, где за это нужно платить.
Как результат — KDE не включается во всякие "RH Pro Edition".
С другой стороны, у создателей KDE есть серьезные намерения портировать KDE под Gtk. Основной аргумент: KDE в основном представляет философию пользовательского интерфейса и не связан со средой разработки. Кроме того, в последнее время часто появляются сведения о "мультиплатформенных" разработках — имеется в виду, что разработчики используют в одной и той же программе и Qt (KDE), и Gtk. В принципе нет ничего, что делало бы невозможным такой вариант — в, частности использование GDK предоставляет значительно больше возможностей для обработки графики, чем соответствующие объекты Qt.
В результатеВ результате — если бы у бабки была репка, то это был бы дедка. То есть: если бы библиотека Gtk была написана на C++, а Qt не была бы защищена лицензиями Trolltech, если бы Qt обладала бы такими же инструментами рисования, как GDK, а Gtk — такой же документацией, как Qt, можно было бы говорить о "тяжелом выборе".
На сегодня же вопрос так не стоит, а стоит вот как: если вам нужно получить быстрое и надежное приложение, если вы не собираетесь использовать различные ObjectCalm’ы и вам не нужно профессиональное рисование (или вы намерены реализовать его самостоятельно) — то вам прямая дорога на сайт Trolltech, искать последнюю версию Qt. Но имейте в виду: за коммерческое использование ребята собирают деньги (за очень коммерческое, однако). А вы зато получите поддержку и другие бонусы. К тому же, помимо графики, Qt еще много чего умеет.
Но если вы убежденный программист на ObjectXLAM (условный Объектный Хлам, не пытайтесь найти по нему мануал), любите свободную тусовку хиппи, бесплатные пирожки на собачьем пуху, а также ориентирование на местности без компаса — счастливого пути на сайт gtk.org, там вы будете как дома.
А чтобы проверить совместимость тулкитов на себе, я как раз и пишу одну "многоплатформенную" программку. Но это уже тема для другой статьи