На чем писать GUI для C++ приложений

Представьте ситуацию: вы пишете-пишете проект, и вдруг этому проекту требуется GUI. И тут вас спрашивают “на чем будем писать?”. Хочу поделиться своими мыслями на тему того, о чем стоит задумываться, перед тем как отвечать на такой вопрос.

Я вам конечно “не скажу за всю Одессу”, но думаю что могу сказать про GUI всяких системных утилит и security-related софта.

На самом деле все фреймворки для написания GUI – проблемные. Я полностью согласен с фразами о том, что какой фреймворк не выбери, написание кода GUI будет не добавлением, а сращиванием. Обязательно придется переделывать код так, чтобы он вписывался в GUI, а не делать GUI на основе существующего кода. Поэтому надеяться на то, что какой-то фреймворк будет лучше для моего проекта – бесполезно. И заявления о том, что какой-то фреймворк лучше подходит для каких-то задач, скорее миф чем правда.

Для подтверждения своих слов вот результат исследования фреймворков используемых в современных приложениях:

Приложение	Фреймворк
acronis true image	QT
skype	QT
araxis merge	свой на основе ATL
teamviewer	WTL
EaseUS Partition Master Home Edition	GTK
Folder Lock	HTMLLayout
agnitum outpost	HTMLLayout
hex workshop	MFC
vmware	свой на основе ATL
trillian	свой на основе GDI+
drweb	MFC + WTL
symantec	SymHTML
kaspersky	QT
NOD	MFC

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

Как вы видите, на любом фреймворке можно написать сложный GUI, и на любом фреймворке можно продолжать его расширять. И как видите, некоторые компании не пугает факт того, что свой делать фреймворк – это долго и сложно. Пишут.

На что же влияет выбор фреймворка?
1) Конечно же фреймворк влияет на внешний вид.

MFC, ATL, WTL и их потомки

Комментировать особо нечего. Если сильно постараться, то можно получить конфету похожую на интерфейс windows 7 (Nod), но в целом получается “классика”.

QT

Белое, но не пушистое, модное направление.

HtmlLayout и производные

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

Экзотика

А GTK-то может быть вполне приятным глазу.

Астру cerulean studios “пилили”, насколько я помню, почти 3 года. Все это время они, похоже, изобретали свой кросплатформенный фреймворк с панелями и виджетами на основе GDI+. Поражаюсь как они смогли так долго не выпускать новых версий и не помереть…

2) Фреймворк влияет на сложность поиска людей
Вот вбили вы себе в голову к примеру, что надо писать GUI только на WxWidgets. Даете объяление, находите какого человека, который думает что знает как писать на wxWidgets. Он начинает делать GUI. GUI растет, кода все больше, а потом этот человек берет и уходит. А за то время, пока вы писали GUI, ситуация изменилась, и желающих писать на wxWidgets больше не осталось. Все ушли на WPF, к примеру. Или еще есть любители wxWidgets, но неспособные разгрестись в сложном GUI, который был создан первым человеком, а профессионалов нет. И что дальше? Переписывать заново?

Поэтому стоит сделать запрос вида “резюме с++ ИМЯ_ФРЕЙМВОРКА” в гугл чтобы оценить сложность поиска человека. На момент написания статьи гугл выдавал вот такое:
MFC – 120000 результатов
WTL – 17600
ATL – 46700
QT – 112000
Htmlayout – 113 (sic!)
GTK – 7600
wxWidgets – 17500
У вас все еще есть вопросы?
Конечно же, эта статистика гугла не говорит о том, что ATL-программиста ровно в 3 раза легче найти, чем WTL-программиста. Но какая-то корреляция здесь есть: ATL-программистов все же проще будет найти, чем человека для GTK или WTL.

Для полноты картины:
C# WPF – 1280000 результатов! Мухи не ошибаются

3) Фреймворк влияет на разработку
И вот только в-третьих стоит начинать думать, о том грабли какого фреймворка, вас ударят менее сильно. Фреймворки навязывают размер приложения, одинаковый/изменчивый внешний вид под разными ОС и темами рабочего стола, сложность создания кастомных контролов, способ создания MUI и хранения ресурсов, степень корявости UI-дизайнера, шаблоны проектирования, но это уже холиварная тема…