Чому більше Q6 не написано на Qt? [зачинено]

Наскільки я знаю і зрозумів у своєму досвіді роботи з Qt, це дуже хороша та проста у навчанні бібліотека. Він має дуже добре розроблений API і є кросплатформенним, і це лише дві з багатьох функцій, які роблять його привабливим. Мені цікаво знати, чому більшість програмістів не використовують Qt. Чи є дефіцит, який говорить проти цього? Яка особливість робить інші бібліотеки кращими за Qt? Чи пов'язане питання з ліцензуванням?

Я насправді не маю намір це бути хиткою відповіддю, але це причини, які я особисто не використовую Qt. Про це можна сказати багато хороших речей - а саме те, що API працює більшу частину часу і що він безперешкодно перемикає платформи. Але я не використовую Qt, оскільки:

1. У деяких випадках він просто не схожий на рідні програми. Проектування єдиного інтерфейсу користувача для всіх платформ по суті не буде добре виглядати при переході з машини на машину з різних причин візуального стилю. Наприклад, на комп'ютерах Mac розбиті смуги зазвичай відносно товсті, а кнопки невеликі та закруглені піктограмами. На машинах Windows розрізні смуги зазвичай вузькі, а кнопки - більш текстові, з більш квадратними конструкціями. Тільки тому, що ви можете написати один інтерфейс для кожної платформи, це не означає, що ви повинні для більшості програм.
2. Qt не є бібліотекою C ++. Це вимагає окремого кроку компіляції, що робить процес збирання набагато складнішим у порівнянні з більшістю інших бібліотек.
3. В результаті (2), C ++ IDE та інструменти можуть позначати вирази 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 -in-qt-step-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 ++. Кожна мова та рамки мають свої плюси і мінуси. Це дуже, дуже складне питання, яке, як правило, може бути узагальнене за допомогою додавання, яке часто зустрічається в закусочних: швидкість, якість та ціна (але ви можете вибрати лише два).

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

1. Qt - це фактично файли бібліотеки / рамки / заголовки C ++. Це доповненоза допомогою макропроцесора (moc), який включає сигнали та слоти, серед іншого. Він перетворює додаткові макрокоманди (наприклад, Q_OBJECT), щоб у класах було самоаналіз та всілякі інші смаколики, які можна подумати як додавання функціональності Objective-C до C ++. Якщо ви знаєте достатньо про C ++, щоб образитися на цю відсутність чистоти, тобто ви професіонал, то 1) не використовуйте Q_OBJECT та його подібні або 2) будьте вдячні, що це робить, і програмуйте навколо дуже обмежених кутових випадків де це спричиняє проблему. Для людей, які кажуть "Використовуйте 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 ITSELF, а не поділитися, або приховати той факт, що користуєтесь 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)#Ліцензування деяких історій ліцензування. До 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 для візуальної студії робить це автоматично, як і власний командний рядок Qt. Компілятор ресурсів, який використовується для створення діалогів для MFC, також є окремим кроком, але це все ще c ++.

Qt - це велика кількість джерела, яке має бути присутнім та попередньо встановленим на будь-якій машині, яку ви використовуєте перед компілюванням. Це може зробити налаштування середовища побудови набагато більш втомливим.

Існує бінарне завантаження для кожної версії візуальної студії, і збірка з джерела - це одна команда. Я не бачу, що розмір джерела SDK в наші дні не так угодний. Visual studio тепер встановлює всі C ++ libs, а не дозволяє вам вибирати та вибирати, в результаті розмір інсталятора компілятора становить> 1Gb.

Він доступний лише під LGPL, що ускладнює використання одно-бінарного розгортання, коли потрібно випускати за ліцензією більш обмежувальної чи меншої кількості.

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

У деяких випадках він просто не схожий на рідні програми. Проектування єдиного інтерфейсу користувача для всіх платформ по суті не буде добре виглядати при переході з машини на машину з різних причин візуального стилю.

Тут слід використовувати рідні віджети та теми. Я мушу визнати, що я в основному технічні додатки, тому мої користувачі не надто переймаються стилем. Тим більше, що в Windows нова мода на те, що все є стиль як смартфон віджет, означає, що стандартів все одно менше.

Причина проста: він не має гарних прив’язків до всіх основних мов, і це не магічно завжди підходить для роботи, що знаходиться під рукою.

Скористайтеся правильним інструментом для роботи. Якщо я пишу просту програму командного рядка, чому б я роздував це з Qt просто заради цього?

Що стосується більш загальної відповіді (яку я можу дати, тому що я тут актуальна), деякі програмісти просто ніколи не дадуть їй піти і вирішили використовувати її. У деяких випадках немає жодної конкретної причини, крім того, що програміст ніколи не знаходив потреби в цьому і не заглядав у нього.

Рамки типу Qt доцільні, коли ви більше переймаєтесь тим, як ваш продукт виглядає однаково на всіх платформах, ніж ваш продукт виглядає правильно на всіх платформах. В наші дні все частіше такі програми переходять на веб-технології.

Я погоджуюся, що Qt - це приємна основа для роботи. Однак у мене є низка питань:

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

При цьому я люблю використовувати PyQt для швидкого прототипування додатків або внутрішніх додатків. Використання Python для виконання кодування полегшує проблеми C ++ і фактично робить Qt дуже приємним місцем.

Редагуйте у відповідь на деякі коментарі:

Коли я писав про те, що Qt пишеться на C ++, я не стільки скаржився на сам Qt, скільки більше на навколишнє середовище, в якому живе. Це правда, що Qt дуже добре керує власними ресурсами, але всі ваші графічні інтерфейси пов'язані з графічним інтерфейсом. код не-Qt теж повинен бути записаний на C ++. Навіть там Qt надає багато приємних інструментів, але в кінцевому підсумку вам доведеться мати справу з C ++ на цьому рівні. Qt робить C ++ переносимим, але це все-таки C ++.

Що стосується самоаналізу, то, що я маю на увазі, це таке: Найважчі випадки налагодження - це коли у вас є вказівник на якийсь об’єкт, який веде себе не так, як ви думаєте, як слід. За допомогою C ++ ваш налагоджувач може трохи заглянути всередині цього об'єкта (якщо трапляється інформація про тип у точці wwt), але навіть це не завжди працює. Візьміть, з іншого боку, какао в тій же ситуації. У програмі 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 віджети не подають необхідних сигналів для простих віджетів подій. Наприклад, ви не можете встановлювати сигнали для onHover, onMouseEnter, onMouseLeave, onKeyReleased, onLostFocus, onGainFocus тощо. Навіть найскладніший віджет, такий як QTreeWidget, надає один або два надпрості непотрібні сигнали.

Так, ви можете використовувати події, АЛЕ !!! ви створили новий клас для кожного віджета за допомогою спеціальної події. Це величезна втрата ефективності;

• Ви переписали кожну індивідуальну подію об’єкта віджета, там є невеликі зміни.
• Ви втрачаєте всі речі дизайнера Qt. Ви повинні рекламувати кожен віджет за допомогою спеціальних заходів.
• Проект став більшим і важким для обслуговування.
• Ви через це не любите qt. І почати говорити про те, як .net надає делегатів, як це набагато набагато краще, ніж слот сигналу, як .net компоненти (віджети) загалом надають кожну подію, яку ви можете собі уявити. І т.д.

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

Однак Qt - найкраща система C ++ UI на даний момент із падіннями та підйомами.

на мою власну думку, вивчення програмування на C ++ простіше, ніж потрапляння на інші мови, які приховують їх складність, і програміст не знає, що насправді відбувається на задньому плані. Qt, з іншого боку, додає певних переваг над C ++, щоб зробити його вищим рівнем, ніж рідний C ++. Таким чином, Qt C ++ є чудовою основою для того, хто хоче розробити завдання низького рівня, або ті, що мають високий рівень, таким же чином. C ++ - це (за деякими практиками) складна і проста мова. Складний для того, хто хоче не кидати виклик їй, простий для того, хто йому подобається. Не залишайте цього, оскільки це складність!

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

Люди бувають різними. Так само їх вибір. Одноманітність - це не людська особливість.