Почему не больше настольных приложений, написанных с помощью Qt? [закрыто]

Насколько я знаю и понял из моего опыта работы с Qt, это очень хорошая и простая в освоении библиотека. Он имеет очень хорошо разработанный API и является кроссплатформенным, и это только две из многих функций, которые делают его привлекательным. Мне интересно знать, почему больше программистов не используют Qt. Есть ли недостаток, который говорит против этого? Какая особенность делает другие библиотеки лучше, чем Qt? Вопрос связан с лицензированием?

На самом деле я не собираюсь это называть ответом, но по этим причинам я лично не использую Qt. Об этом можно сказать много хорошего, а именно то, что API работает большую часть времени и плавно соединяет платформы. Но я не использую Qt, потому что:

1. В некоторых случаях это просто не выглядит как нативные программы. Разработка единого пользовательского интерфейса для всех платформ сама по себе не будет выглядеть правильно при перемещении с компьютера на компьютер по различным причинам визуального стиля. Например, на компьютерах Mac разделенные полосы обычно относительно толстые, а кнопки маленькие и округлены с помощью значков. На компьютерах с Windows разделенные полосы обычно узкие, а кнопки более текстовые с более квадратным дизайном. Тот факт, что вы можете написать один пользовательский интерфейс для каждой платформы, не означает, что вы должны делать это для большинства приложений.
2. Qt не является библиотекой C ++. Это требует отдельного шага компиляции, что значительно усложняет процесс сборки по сравнению с большинством других библиотек.
3. В результате (2) IDE и инструменты C ++ могут помечать выражения Qt как ошибки, потому что они не понимают специфику Qt. Это почти заставляет использовать QtCreator или текстовый редактор vim.
4. Qt - это большое количество исходного кода, который должен присутствовать и предустанавливаться на любой машине, которую вы используете перед компиляцией. Это может значительно усложнить настройку среды сборки.
5. Он доступен только в рамках LGPL, что затрудняет использование одного бинарного развертывания, когда нужно выпустить под более ограничительной или менее ограничительной лицензией.
6. Он генерирует чрезвычайно большие скомпилированные двоичные файлы по сравнению с аналогично написанными «простыми старыми приложениями» (за исключением приложений, написанных для KDE).

Как говорят люди, каждый инструмент подходит для каждой проблемы и ситуации ...

Но если вы программист на C ++, Qt - ваш фреймворк. Нет соперника.

Мы разрабатываем комплексное коммерческое приложение для медицинской визуализации, и Qt держится.

Я не говорю, что «минусы», которые люди говорят об этом, являются ложными, но у меня есть ощущение, что они не пробовали Qt в течение длительного времени (он постоянно улучшается с каждой новой версией ...) И, в основном, все вопросы, которые они комментируют, не являются проблемой, если вы позаботитесь.

Несогласованность платформы пользовательского интерфейса: только если вы используете виджеты пользовательского интерфейса «как они есть», без каких-либо настроек или пользовательских рисунков.

Перегрузка препроцессора Qt: Только если вы используете механизм слотов сигналов или наследование QObject, когда в этом нет особой необходимости.

Кстати, мы до сих пор пишем приложения на C # .NET и занимаемся этим уже давно. Поэтому я думаю, что у меня есть перспектива.

Как я уже сказал, каждый инструмент для каждой ситуации,

но Qt, без сомнения, является последовательной и полезной основой.

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

template < typename T >
struct templated_widget : QWidget
{
  Q_OBJECT;

public signals:
  void something_happened(T);
};

Это также не очень хорошо с препроцессором. Вы не можете сделать это:

#define CREATE_WIDGET(name,type) \
struct name ## _widget : QWidget \
{ \
  Q_OBJECT; \
\
public signals: \
  void something_happened(type); \
}

Это, в сочетании с тем фактом, что все, что реагирует на сигнал, должно быть Q_OBJECT, делает Qt трудным для программиста на C ++. Люди привыкли к программированию в стиле Java или Python, вероятно, на самом деле лучше.

На самом деле я потратил много времени и усилий на исследование и разработку способа вернуть безопасность типов и подключить сигнал Qt к любому объекту-функтору: http://crazyeddiecpp.blogspot.com/2011/01/quest-for-sane-signals -в-кварта шаг-1.html

То, что я хочу сделать, - это базовая, повседневная разработка на C ++, которую Qt moc делает практически невозможной ... что само по себе совершенно не нужно в наши дни, если это вообще было так.

Честно говоря, я застрял с этим, потому что, если вы хотите проводить автоматическое тестирование пользовательского интерфейса, Qt является практически единственной игрой в городе, кроме MFC ... которая так 1980 года (это ужасно тяжело работать в этом дерьме). Кто-то может сказать, WX, но у него есть еще более серьезные проблемы. GTKmm был бы моим первым выбором, но так как он все нарисован владельцем и не обеспечивает доступность ... не может управляться стандартным программным обеспечением тестирования. Qt достаточно сложен в этом отношении ( едва работает, когда вы изменяете плагин доступности).

Одна из причин не использовать Qt состоит в том, что если вы пишете только для одной архитектуры, такой как Windows, вы можете использовать C # / .NET (или Cocoa на Mac), потому что они всегда смогут воспользоваться преимуществами последних звонков-и - свистит из ОС.

Если вы пишете кроссплатформенные приложения, то вы, возможно, уже в значительной степени наделены другой технологией, такой как Java (т.е. вы работаете в «магазине Java»). Ваш выбор технологии может быть продиктован экосистемой, в которой вы разрабатываете, такой как специфичные для языка API. В подобных случаях минимизация количества технологий может быть полезной.

Третья причина, о которой я могу подумать, заключается в том, что Qt основан на C ++, а C ++ является сравнительно сложным / опасным языком для программирования. Я думаю, что это язык для профессионалов. Если вам нужна максимальная производительность и способность быть дотошным, то C ++, вероятно, все еще остается лучшей игрой в городе. На самом деле, Qt облегчает многие проблемы управления памятью, если вы настраиваете их на выпадение из области видимости. Кроме того, сам Qt хорошо защищает пользователя от многих неприятных проблем C ++. У каждого языка и основы есть свои плюсы и минусы. Это очень, очень сложный вопрос, который обычно можно суммировать с помощью надстройки, часто встречающейся в закусочных: скорость, качество и цена (но вы можете выбрать только два).

Хотя правила говорят, что я должен сосредоточиться на ответе на этот вопрос, я хочу опровергнуть некоторые из вопросов, поднятых Билли Онилом, который, я думаю, хорошо справляется с обобщением часто цитируемых причин, по которым не следует использовать Qt:

1. Qt действительно является C ++ библиотекой / framework / заголовочными файлами. Он дополненмакропроцессором (moc), который включает сигналы и слоты, среди прочего. Он преобразует дополнительные макрокоманды (такие как Q_OBJECT), так что у классов есть самоанализ и всевозможные другие полезности, о которых вы можете подумать как о добавлении функциональности Objective C в C ++. Если вы знаете достаточно о C ++, чтобы обижаться из-за отсутствия чистоты, то есть вы профессионал, то 1) не используйте Q_OBJECT и тому подобное или 2) будьте благодарны за это и программируйте в очень ограниченных случаях где это вызывает проблему. Для людей, которые говорят: «Используйте Boost для сигналов и слотов!» тогда я бы сказал, что вы обмениваете одну «проблему» на другую. Boost огромен, и у него есть свои часто упоминаемые проблемы, такие как плохая документация, ужасные API и кроссплатформенные ужасы (подумайте о старых компиляторах, таких как gcc 3).

2. Для поддержки редактора это также следует из 1, я несколько согласен. На самом деле, Qt Creator - ИМХО лучший графический редактор C ++, даже если вы не используете материал Qt. Многие профессиональные программисты используют emacs и vim. Кроме того, я думаю, что Eclipse обрабатывает дополнительный синтаксис. Таким образом, нет проблем с макросами Qt (Q_OBJECT) или добавлениями сигналов / слотов. Вы, вероятно, не найдете эти макросы в Visual Studio, потому что (я признаю) они являются дополнениями к C ++. Но, в общем и целом, люди из C # / .NET в любом случае не собираются использовать Qt из-за того, что они обладают большой функциональностью, покрытой их собственными проприетарными методами.

3. Что касается размера источника Qt, если он компилируется за ночь, кого это волнует? Я скомпилировал Qt 4 на своем двухъядерном Macbook «меньше, чем за ночь». Я, конечно, надеюсь, что это не то, что движет вашим решением использовать или не использовать определенную технологию. Если это действительно проблема, то вы можете скачать предварительно скомпилированные SDK для Mac, Linux и Windows с веб-сайта Qt.

4. Лицензирование доступно в трех вариантов: 1) Фирменные лицензии в случае , если вы хотите изменить Qt самих и не делиться, или скрыть тот факт , что один использует Qt и не готов дать атрибуции (может быть очень важно для брендинга и изображений) 2! ) GPL и 3) LGPL. Да, есть проблемы со статическим линкованием (сворачивание всего Qt в двоичный файл) - но я думаю, что это больше, потому что нельзя заглянуть внутрь и заметить, что вы используете Qt (атрибуция!). Я пытался купить проприетарную лицензию у Digia, и они сказали мне: «за то, что ты делаешь, тебе это действительно не нужно». Ух ты. От бизнеса, который занимается продажей лицензий.

5. Размер двоичного файла / пакета связан с тем, что вы должны распространять материал Qt людям, у которых его нет: Windows уже есть? Visual Studio материал или вы должны установить во время выполнения. Mac уже поставляется с огромным Какао и может быть динамически связан. Хотя я не занимаюсь распространением, я никогда не сталкивался с проблемой распространения статического файла размером ~ 50 мегабайт (который я могу сделать еще меньше с помощью некоторых утилит для бинарного удаления / сжатия, таких как UPX). Мне просто все равно, чтобы сделать это, но если бы пропускная способность была проблемой, я бы добавил шаг UPX в мой скрипт сборки.

6. Что определяет "Родной взгляд и чувство?" Я думаю, что «большинство» согласится с тем, что Mac ближе всего подходит к единому внешнему виду. Но здесь я сижу, глядя на Safari, iTunes, Aperture, Final Cut Pro, Pages и т. Д., И они ничем не похожи, несмотря на то, что они сделаны производителем ОС. Я думаю, что аспект «чувствовать» является более актуальным: стилизация виджетов, отзывчивость и т. Д. Если вы заботитесь об отзывчивости, то здесь есть веская причина использовать C ++, а не Java или какой-либо другой высокодинамичный язык. (Цель C тоже потрясающая, но я пытаюсь развеять мифы о Qt)

Таким образом, это сложный вопрос. Но я хотел бы отметить, что я думаю, что есть меньше причин «не использовать Qt», как можно подумать, основываясь на мифах и устаревшей информации.

Частично это лицензирование. См. Https://en.wikipedia.org/wiki/Qt_(software)#Licensing для некоторых из истории лицензирования. До 2000 года люди, которые сильно интересовались открытым исходным кодом, не использовали Qt. Период. (Это было, по сути, первоначальной мотивацией для разработки Gnome.) До 2005 года люди, которые хотели иметь возможность выпускать бесплатное программное обеспечение для Windows, не использовали Qt. Даже после этой даты люди, которые хотели свободного программного обеспечения под чем-то иным, чем GPL, просто не имели возможности использовать Qt. Таким образом, любой проект свободного программного обеспечения, который старше этих дат, не может использовать Qt. И, конечно, люди, пишущие собственный код, должны были заплатить за эту привилегию.

Кроме того, это не так, как будто есть нехватка других вариантов. Например, WxWidgets , GTK + и Tk - это кроссплатформенные наборы инструментов с открытым исходным кодом.

Кроме того, долгое время Windows была настолько доминирующей на настольных компьютерах, что многие программы содержали контент только для Windows. Если вы устанавливаете набор инструментов Microsoft, проще просто использовать проприетарные вещи Microsoft, чем беспокоиться о чем-то другом, и многие программисты так и сделали.

Я согласен почти со всеми причинами, описанными выше, однако многие люди здесь сказали, что они не будут использовать Qt из-за дополнительных издержек, которые он несет с собой. Я не согласен с этим, потому что все наиболее распространенные на сегодняшний день языки (Java, C # и Python) несут немалые накладные расходы сами.

Во-вторых, Qt делает программирование на C ++ настолько простым и понятным, что компенсирует дополнительные ресурсы, которые он использует. Я встречал довольно много консольных приложений, написанных на Qt, а не на стандартном C ++, из-за легкости их написания.

Я бы сказал, что производительность Qt выше, чем у C / C ++, но меньше, чем у таких языков, как Python.

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

Вероятно, настоящая причина того, что Qt не так широко используется, заключается в том, что это C ++, и все меньше людей используют c ++ для настольных приложений.

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

Vs-addin для visual studio делает это автоматически, как и собственный процесс создания в Qt. Компилятор ресурсов, используемый для создания диалогов для MFC, также является отдельным шагом, но это все еще c ++.

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

Существует бинарная загрузка для каждой версии visual studio, а сборка из исходного кода - это одна команда. Я не вижу, что размер исходного кода SDK так важен в наши дни. Visual Studio теперь устанавливает все библиотеки C ++, а не позволяет вам выбирать, и в результате размер компилятора составляет> 1 ГБ.

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

LGPL относится только к lib, это не влияет на ваш код. Да, это означает, что вы должны поставлять DLL, а не один двоичный файл (если вы не платите), но в мире, где вам нужно загрузить среду выполнения Java или обновление .Net для крошечной утилиты, это не такая уж большая проблема. Это также меньше проблем на платформах с одним ABI, так что другие приложения Qt могут делиться библиотеками.

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

Предполагается использовать родные виджеты и темы. Я должен признать, что я делаю в основном технические приложения, поэтому мои пользователи не слишком заботятся о стиле. Особенно в Windows новая мода на то, чтобы все стилизовалось под виджет для смартфона, означает, что в любом случае стандарта становится все меньше и меньше.

Причина проста: у него нет хороших привязок ко всем основным языкам, и это не всегда волшебно подходит для работы под рукой.

Используйте правильный инструмент для работы. Если я пишу простое приложение для командной строки, зачем мне это раздувать с помощью Qt просто ради этого?

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

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

Я согласен с тем, что Qt - хорошая среда для работы. Тем не менее, у меня есть ряд проблем:

1. Он написан на C ++, который является языком действительно низкого уровня. Один только тот факт, что это C ++, сделает каждого программиста Qt значительно менее продуктивным по сравнению с Frameworks, написанным на других языках. Моя главная претензия к C ++ как к языку разработки GUI состоит в том, что в нем практически отсутствует понятие автоматического управления памятью, что делает процесс разработки намного более подверженным ошибкам. Это не интроспективно, что делает отладку намного сложнее. Большинство других основных инструментов GUI имеют некоторое представление об автоматическом управлении памятью и самоанализе.
2. Каждый кроссплатформенный инструментарий страдает от проблемы, заключающейся в том, что он может реализовать наименьший общий знаменатель из всех поддерживаемых платформ. Это, а также различные рекомендации по пользовательскому интерфейсу на разных платформах в значительной степени ставят под сомнение целесообразность кроссплатформенных графических интерфейсов в целом.
3. Qt очень сильно сконцентрирован на кодировании всего вашего пользовательского интерфейса. Несмотря на то, что вы можете использовать QtDesigner для создания некоторых частей вашего пользовательского интерфейса, он серьезно отсутствует по сравнению, скажем, с (Cocoa / Obj-C) Interface Builder или инструментами .Net.
4. Несмотря на то, что Qt включает в себя множество низкоуровневых функциональных возможностей приложения, его нельзя сравнить с наличием платформы, адаптированной для конкретной платформы. Собственные библиотеки операционной системы для Windows и OSX значительно более мощные, чем реализации Qt. (Вспомните звуковые рамки, низкоуровневый доступ к файловой системе и т. Д.)

Тем не менее, я люблю использовать PyQt для быстрого прототипирования приложений или собственных приложений. Использование Python для выполнения всего кодирования облегчает проблемы с C ++ и фактически делает Qt очень приятным местом.

Отредактируйте в ответ на некоторые комментарии:

Когда я писал о том, что Qt написан на C ++, я не столько жаловался на сам Qt, сколько на среду, в которой он живет. Это правда, что Qt очень хорошо управляет своими собственными ресурсами, но все ваши GUI-связанные, но- код not-Qt также должен быть написан на C ++. Даже там Qt предоставляет много хороших инструментов, но в конечном итоге вам придется иметь дело с C ++ на этом уровне. Qt делает C ++ переносимым, но это все еще C ++.

Что касается самоанализа, то я имею в виду следующее: самые сложные случаи для отладки - это когда у вас есть указатель на какой-то объект, который ведет себя не так, как вы думаете. С C ++ ваш отладчик может немного заглянуть внутрь этого объекта (если в нем есть информация о типе на данный момент), но даже это не всегда работает. Взять, с другой стороны, Какао в той же ситуации. В Cocoa / Obj-C вы сможете отправлять сообщения («функции вызова») объекту прямо в отладчике. Вы можете изменить состояние объекта, запросить его атрибуты, запросить его тип и имена функций ... Это может сделать отладку намного удобнее. Qt / C ++ не имеет ничего даже близко к этому.

Мне действительно нравится Qt, но он немного тяжеловесен для многих приложений. Иногда вам просто не нужен этот уровень сложности. Иногда вам просто нужно что-то простое без всяких накладных расходов на Qt. Не каждое приложение должно быть управляемым событиями, и C ++ предоставляет разумный набор шаблонов. Boost предоставляет еще один очень хороший набор и включает в себя множество низкоуровневых функций (файлов, сокетов, управляемых указателей и т. Д.), Которые делает QT.

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

У некоторых есть соображения безопасности или стабильности, которые не позволяют использовать сложные библиотеки, такие как Qt.

Вам нужно запустить moc для предварительной обработки ваших источников. Это не большая проблема, но она может быть сложной для нового пользователя. Многие программисты думают, что вам нужно использовать qmake с Qt, но это неправильно. Можно довольно легко подключить Qt к другим системам сборки.

Некоторые цели очень ограничены в памяти или процессоре.

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

Это только C ++. Существуют другие языковые привязки, но они, как правило, скрывают или плохо раскрывают многие функции, для которых вы хотите использовать Qt.

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

Самое важное, но не упомянутое. В большом проекте одна вещь вызывает столько проблем и ненужного кода. Механизмы слотов сигналов Qt неэффективны. Qt widgets не предоставляет необходимые сигналы для простых виджетов событий. Например, вы не можете установить сигналы для onHover, onMouseEnter, onMouseLeave, onKeyReleased, onLostFocus, onGainFocus и т. Д. Даже самый сложный виджет, такой как QTreeWidget, предоставляет один или два ультра простых бесполезных сигнала.

Да, вы можете использовать события, НО !!! у вас есть новый класс для каждого виджета с пользовательским событием. Это огромная эффективность, потерянная;

• Вы переписали каждое настроенное событие объекта виджета с небольшими изменениями.
• Вы теряете все вещи Qt Designer. Вы должны продвигать каждый виджет с помощью пользовательских событий.
• Проект стал больше и его сложнее поддерживать.
• Вы начали не любить qt из-за этого. И начинаем говорить о том, как .net предоставляет делегатов, как он намного лучше, чем сигнальный слот, как компоненты .net (виджеты) обычно предоставляют каждое событие, которое вы можете себе представить. И так далее.

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

Тем не менее, Qt является лучшим C ++ UI-фреймворком на данный момент со взлетами и падениями.

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

Фактическая причина не техническая.

Люди бывают разные. Как и их выбор. Равномерность - это не человеческая черта.