Космічна одіссея qt 5 очима програміста на c ++

Відео: Уроки програмування на C ++ з Qt 5 1 1 5 2 Урок 4 QCheckBox, QTimer, Release

Статтю про Qt 5 я виношував давно, ще до випуску цієї самої п`ятої версії, коли вона тільки планувалася і розробники Qt5 засмутили хардкорних програмістів на C ++ повідомленням, що Qt Quick став «громадянином першого класу».

Те, що відбувалося з бібліотекою Qt в останні роки, хвилювало всіх, хто пов`язав свої програми з цієї вже не просто бібліотекою, а справжньою платформою.

Мабуть, тільки команда KDE випромінювала оптимізм і на ура приймала крен Qt в сторону технології Qt Quick, де замість коду на С ++ пропонується писати код на діалекті javascript -QML, а іграшковий, заточений під мобільні пристрої інтерфейс, будувати в графічному WYSIWYG-редакторі .

Сам Qt Quick увійшов до складу Qt в 2010 році, і сталося це не просто так, а коли Qt розроблялася під «крилом» Nokia. Nokia збиралася поставити Qt в основу програмування для системи Symbian.

Всі сили були кинуті, в буквальному сенсі, на «мобілізацію» Qt. Чи думав хтось про програмістів, що використовують С ++? Що нового для них з`явилося тоді в Qt? Не так вже й багато...

Лише через рік Nokia відмовляється від розвитку системи Symbian. Однак розробка Qt продовжує котитися на «мобільних» рейках: розробники Qt не чують аргументів спільноти програмістів. Коли Qt була продана компанії Digia, напрямок розробки залишилося колишнім. І ось в грудні 2012 року вийшла Qt 5 (https://blog.qt.digia.com/blog/2012/12/19/ qt-5-0).


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




Модульність кульгала: наприклад, по документації (навіть до гілки 4.х), WebKit можна відключити параметром -no-webkit, але потім виявлялося, що цей параметр не працює, треба використовувати --no-webkit, але і він не спрацьовував, і доводилося правити исходники файлів налаштувань збірки. А тим часом саме WebKit - головне гальмо збірки Qt і головний винуватець невдалих спроб складання. Але ж не всім він потрібен.

Перед випуском Qt 5 розробники чесно попередили, що API буде «поламаний» і що до нього доведеться адаптувати код. Добре, нічого страшного: опишіть зміни, а ми пристосуємо код.

Програмістам надали два документа: C ++ API changes (https://qt-project.org/doc/ qt-5.0 / qtdoc / sourcebreaks.html) і Porting C ++ Applications to Qt 5 (https://qt-project.org/doc /qt-5.0/ qtdoc / portingcppapp.html), а також загальний The Transition from Qt 4.x to Qt 5 (https://qt-project.org/ wiki / Transition from Qt 4.x to Qt5) з описом змін (документацію щодо змін QML я ігнорую, але взагалі вона теж існує).




Однак відомостей з цих документів для успішного портування програми з Qt4 на Qt5 недостатньо. І мова йде не про дрібниці!

Наприклад, підтримка друку не працює, поки в qmake-файл не додати рядок:

Взагалі для qmake-файлів, сумісних з обома версіями Qt, корисно писати так:

Якщо основна версія більше 4, додаємо модулі widgets і printsupport, інакше - нічого не робимо або виконуємо щось специфічне.

Інший момент, який коротко документували, - зникнення макро-визначення Q_WS_WIN. З давніх-давен в C ++ / Qt для ділянок коду, який потрібно було зібрати під Windows, використовувалася перевірка, чи визначено Q_WS_WIN.

Виглядало це ось так:

В Qt 5 замість Q_WS_WIN треба використовувати Q_OS_WIN. Чому не залишити і Q_WS_ WIN? Адже багато програм будуть «мовчки» скомпільовані з кодом, заточеним під іншу систему. Як і чим це відгукнеться, поки програмісти конкретної програми не схаменуться, сказати важко.