Як зрозуміти, що прога написана на Qt? — Ніхто не вміє працювати з High-DPI екранами 🧐 Навіть дефолтний #QML-проєкт, що генерується в Qt Creator з офіційного шаблону, містить некоректний код для Windows.

В даному випадку бачимо завеликі іконки в macOS. Що цікаво: на рідному retina-екрані макбука як раз все ок, а це скріншот з мого «звичайного» монітора.

Хоч бери й пиши мануал.

Я вже неодноразово згадував, що моя найулюбленіша система збирання проєктів — це #Qbs. Базується цей вибір на двох суперобʼєктивних причинах авжеж: 1) на хибному першому враженні, що за мову там використовують #QML (90% збігається, але насправді це не вона, від чого реально палає нерідко), та 2) на тому, що не можу терпіти #CMake 😁

В кьюбсі в найпростішому вигляді достатньо викликати qbs build або навіть qbs run, й він все сам зробить. Втім інколи треба додати пару якихось ключів в команд-лайн, які я безумовно не памʼятаю. Що в таких випадках люди роблять першочергово? Правильно, пишуть qbs build --help. Але це суперечить концепції(!) головного розробника, тому наразі результат отакий:

ERROR: Invalid use of command 'build': Unknown option '--help'.
Type 'qbs help build' to see how to use this command.

Концептуальність — це завжди офігезно авжеж, але не тоді, коли це щодня наламує мені UX. Так, я не можу спеціально для цієї тулзи тримати в памʼяті, що треба писати qbs help build замість qbs build --help, бо в нормальних прогах це тотожні виклики.

Тож я пішов та зробив свій перший внесок в Qbs аж на пʼять рядків коду, який це виправляє 😂 Довелось заради цього навіть gerrit налаштувати собі з його ґітовими гуками.

Сьогодні вмержив 🥳🍾

А ще питають такі:
— А на чому писати збираєшся?
— На C++ та #QML авжеж! (Хоча зараз думаю, що легше на Python+QML)
— У-у-у-у… Наші люди тільки на сішарпі та ангулярі вміють…

І важко їх звинуватити в чомусь. The #Qt Company просрала можливість зайняти нішу на десктопах (та й на решті систем втрачає позиції). Шкода, бо QML сама по собі дуже прикольна 😢 Але недовго їй лишилось, мабуть.

Зробили з друганом лібу на С++ та байндінги для #QML, щоб керувати Elgato Stream Deck напряму без їхньої офіційної апки (ну й емулятор також на випадок, якщо фізичного пристрою немає). Точніше як зробили… Здебільшого він зробив авжеж, але мені як менеджеру теж можна хизуватись, я вважаю 😇

В імплементації протокола надихалися лібою на Python, яка в свою чергу списувала у ліби на Node.js. Так і живемо 🤷‍♂️

Поки що немає, що ще показати, але як буде більш-менш стабільним, скину посилання.

ISO C++ створили щорічне опитування пару днів тому (валідне буде тиждень всього).

Останнім часом на С++ тиск підсилився, бо той же Rust з memory safety підпирає. Доходить до того, що Страуструп вкотре виправдовується, мовляв, «нормальна безпечна мова — то у вас руки зі сраки».

Я в чомусь згоден, у чомусь — ні. Але ви подивіться на запитання. Наприклад, «що вас найбільше дратує в розробці на C++?» І у відповідях зокрема аж три окремі можливості зазначити, що «memory safety для мене не є проблемою» 😂 (А багатьом програмістам і справді пофігу, бо це ж не вони гроші втрачатимуть якщо що).

Або: «чи дозволено вам на роботі користуватися модулями з C++20?» Ну, дозволено-то дозволено, але ж вони не працюють нормально — підтримка компіляторами щось якось частково є, а білд-системи здебільшого не альо тощо.

C++ точно не помре найближчим часом, але хз навіть, які перспективи.

Ну ви-то більшість і не плюсисти мабуть взагалі. А я на C++ досі пишу тільки тому, що мені подобається робити UI на #QML 🙂

Якщо хтось чекав на можливість нарешті використовувати #QML у ваших WPF-програмах під 💻 (вже ніхто не чекав), wait no more.

Схоже, втративши купу ринків, 💻 раптово збагнула, що було б непогано мати офіційні байндінги до інших мов окрім 💻 та 💻, і хтось там у них написав кастомний нейтів хост під .NET.

Можливо, #QML — це наразі одна з найвагоміших причин, чого я досі тримаюся C++. Я просто дуже полюбляю робити UI, і саме завдяки цим двом мовам я здатен досягати найшвидших та найякісніших результатів. Python відштовхує своєю повільністю виконання та труднощами розповсюдження готових програм. А під інші мови всі байндінги сумнівної якості й написані хтозна-ким.

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

Ух, 💻 прям активізувалася 🤔 Нещодавно релізнули екстеншн до vscode 💻 з language server для #QML (екстеншн лайно, проте, як перший крок норм), а зараз ось зробили плагін для Gradle, щоб легше було під Android 💻 збирати.

Розповім ще невеличку історію про 💻 та #QML, але не стільки з технічними деталями, скільки з архітектурними.

Отже, частиною Qt є UI-фреймворк під назвою Qt Quick. Він звісно на С++ написаний, але користувачі переважно на QML пишуть. Всі візуальні елементи там є нащадками Item. Ну й за роки розвитку він вже добряче навбирав у себе різних спільних властивостей та став дещо важкеньким.

Серед базових важливих властивостей, що були там з самого початку, є так звані anchors — механізм дуже легко робити flexible UI. Наприклад, пишете

height: 35
anchors.bottom: parent.bottom

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

Хоч на анкорах майже будь-що можна зробити, та не завжди це зручно. Якихось більш високорівневих лейаутів не було, й згодом їх додали окремим модулем QtQuick.Layouts. Відтоді стало можна писати якось отак:

RowLayout {
  TextField { Layout.fillWidth: true }
  Button { text: 'Submit' }
}

Ця штука автоматично позиціює елементи в рядок. Причому поле для вводу текста розтягнеться на всю можливу ширину, а кнопка буде мінімально можливого для себе розміру. Доволі зручно, хоча в певних випадках вкрай важко змусити ці лейаути робити те, що тобі треба, бо вони переускладнені відчутно. Не flexbox, звісно, але у мене в голові червона лампочка складності вже мерехтить.

Та весь кайф був у тому, що ніхто QtQuick.Layouts не навʼязував. Не подобається, як вони працюють? То напиши свій (на C++)! Так і зробив мій друган, що тоді був девелопером у моїй команді. І тепер його лейаут «катається» у сотнях тисяч Мерседесів з MBUX.

Та, схоже, не всім це було до душі. Виявилося, що комусь занадто складно розставляти fillWidth/fillHeight у потрібних місцях 🤦🏻‍♂️ Це, як на мій погляд, не велика проблема, бо QML дозволяє це суперлегко вирішити створенням нових компонентів. Для цього треба або новий файл створити (1 компонент = 1 файл), або прям inline написати на кшталт:

component FormField: TextField {
  Layout.fillWidth: true
}

RowLayout {
  FormField {}
  Button {}
}

Ну, типу… все! Що може бути краще?

Але якийсь черговий геній в Qt знайшов можливість «пакращєння»:
1) він додав у базовий Item властивість sizePolicy, яка має вказувати кьютовому лейауту, чи розтягувати елемент, чи він мусить мати фіксований розмір.
2) Потім він нахуєвертив «sensible defaults» в усі контроли, що наслідують Item, тобто всі кнопки, текст-філди, слайдери й таке інше.
3) Ці sensible(!) defaults миттєво наламали KDE Plasma, де все поплило, бо не такі вони й sensible виявилося.
4) І на додачу, sizePolicy ще й частина private API, тобто для своїх кастомних лейаутів це буде проблематично використати. Отже, QtQuick.Layout тепер прибитий цвяхами до QtQuick.
Наразі вирішили цю фічу зробити тимчасово opt in, однак, проперті вже там, тож кожен Item позаяк займає більше памʼяті, ніж раніше.

А які задачі ви вигадуєте собі на роботі, щоб не складалося враження, що сидите без діла? 🤣

Де це Сіпласпластик знов подівся? Працює, мабуть…

Ще б пак працює!

Отже, у вільний час, якого на жаль не так багато, потроху допомагаю перекладати гру українською. І щоб перевірити локалізацію на власне грі, треба стягнути поточний файл з перекладом з Crowdin та закинути у потрібну теку.

От тільки файл — це CSV, і Crowdin автоматично огортає кожне значення в лапки, а парсер гри цього не розуміє, бо там розробники не заморочувалися. Ну й додаткові ще якісь реквайрменти до того файлу є.

Що роблять нормальні люди у такому випадку? — Виправляють все файнд-реплейсом у ноутпаді.
Що роблять адекватні люди з навичками програмування? — Пишуть скрипт на 💻 у три рядки, який виправлятиме все автоматично.

Що роблю я? — Я пишу рушій для запуску «правил», написаних на #QML 😅

Отож правила + опціональний логотип (гри) + додаткові файли для копіювання лежать в бандлі. Концепція бандлів з #macOS мені дуже подобається: це така тека з різноманітним мотлохом, але система відображає її як файл і, коли дабл-клікаєш, відкриває відповідну програму. На вінді, звісно, так не працює, тому я просто всередину бандла поклав ще один додатковий порожній файл з кастомним розширенням, і дабл-клікаю там вже по ньому.

QML-рушій крутиться в UI-треді, тож коли йшла обробка файлу, все завмирало, чим дуже мене дратувало. Але виявилося, що можна мати декілька рушіїв в одному процесі! Мені так навіть краще. Я в окремому треді запускаю рушій для опрацювання правил, а в UI-ному тільки… UI. І вони один з одним комунікують там якось сигналами. На одному з етапів розробки у мене так летіло 50к сигналів в секунду 😄, тому UI все одно не реагував — довелося трохи оптимізнути. Зараз там, думаю, ну сотня тих сигналів, може, якщо не менше.

Користувач просто драг-н-дропає файл у вікно, й воно фігачить. Наразі є декілька видів правил:
• FileRule отримує на вхід чисто імʼя файлу й далі робить з ним ті перевірки, що хоче, в колбеці ensure.
• ItemRule запускається для кожного рядку тексту, тож отримує цей рядок та його індекс. Окрім того, можна задефайнити ще fix, який автоматично щось виправлятиме.
• InstallCurrentFile дозволяє поточний файл закинути у якусь теку, опціонально під іншим імʼям.
• InstallFiles — майже те саме, але копіює якісь статичні файли з бандлу.
• Окрім того, існує Group, щоб можна було групувати декілька рулів, а значить — виносити їх в окремі реюзабл-файли! Їх можна вкладати одна в одну, й воно врешті просто «розчиняє» їх, роблячи щось на кшталт flatten.

Люди з команди поки що не дуже оцінили прикол, відреагувавши доволі вʼяло — мабуть, тому що треба текст перекладати, а не хуйнею маятися 😅 Але мене прям бісило руками це робити щоразу, тож я не встояв, бо коли мене щось з інструментів дратує, я весь час про це думаю й не можу сфокусуватися на роботі.

Думаю згодом ще додати можливість порівнювати рядок з оригіналом + підтримку інших форматів на кшталт XLIFF + автоматичний апдейт з Crowdin, щоб руками ото не качати. Але поки що мені й так норм.

Декілька років тому 💻 на своєму World Summitʼі мала доповідь, в якій чувак натякав, що було б цікаво використовувати цю бібліотеку в програмах іншими мовами.

Зараз Qt можна використовувати з C++ (очевидно), плюс є офіційні привʼязки для Python під назвою PySide. Ще промайнули якісь дивні поробки для інтеграції з 💻. На цьому все. Існує безліч неофіційних, та щось довіри до них нема.

Я вже якось згадував, що #QML як мова для використання фреймворка Qt Quick — це одна з останніх вагомих причин, чого я досі користуюся C++. Просто мені подобається робити UI і подобається, коли врешті він працює достатньо швидко й не вимагає 2 ГБ оперативки, як це нерідко буває з туду-програмами на електроні. Втім C++ у своєму поточному стані дійсно далека від приємної мови, хоча я потроху прямує до неї.

Так-от місяць тому пройшов черговий QtWS, де вони нарешті анонсували так звані Qt Bridges. Поки що жодної конкретики, але за їхніми розповідями це якась достатньо високорівнева апішка для інтеграції QML-ного рушія (і, може, не тільки) в програми іншими мовами. Першими їхніми обранцями стали: 💻, Kotlin 💻 і Java 💻, Python 💻, Rust і Swift 🕊. Я особисто найбільше зацікавлений в останньому, бо під час Advent of Code 2024 мені загалом ця мова сподобалася. З іншого боку дуже хотілося б ще мати змогу писати на QML разом з 🦶. Ну й з Janet 👩‍🦰 ще б теж непогано ))

Найбільше в усьому цьому мене зараз хвилює навіть не технічний бік питання, а легальний. Nokia в свій час перевела Qt з GPL на LGPL, що зіграло на руку популяризації бібліотеки. Але зараз ми бачимо, що Qt Group в пошуках додаткових джерел для заробітку робить навпаки: створює нові модулі, інколи попередньо задепрекейтивши «старі» LGPL-ні, і релізить їх тільки під GPL та комерційною ліцензією. Наприклад, Qt Graphs, Qt HTTP Server, Qt Lottie Animation, Qt Quick 3D тощо.

А як хотілося б мати змогу писати UI на QML, а бізнес-логіку на чомусь компільованому, потім збирати це в один невеличкий бінарь — і щоб це все ще й безплатно! 🤑 Хоча, мабуть, легше вже свій рушій для QML написати натомість.