Ads
Comments 301

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


1) Event-based потокобезопасная и быстрая модель взаимодействия почти всего во фреймворке. Самое главное то, что её было ОЧЕНЬ легко использовать и почти не надо было думать. Всё взлетало само, много ума не надо.


2) Богатый набор всего на свете. Тогда Qt воспринимался как boost с человеческим лицом, т.е. вещь в которой можно накопать всё что угодно и это будет работать хорошо и быстро.


3) QML очень удобная вещь.


4) Документация. Долгое время я думал, что на MSDN хорошая документация, но потом я встретил документацию Qt. Ничего более прекрасного я не видел никогда и нигде (в мире С++, в других экосистемах всякое есть).


5) НОРМАЛЬНЫЙ кроссплатформенный (Mac/Win/Lin на то время) GUI фреймворк. Где всё работало блин. А если не работало, требовались прямо вот совсем минимальные подпрыгивания. Шрифты не уезжают, поддержка нативных контролов есть, ничего не тормозит "на глаз".


6) На тот момент единственная бесплатная вменяемая кроссплатформенная C++ IDE


7) qmake (вроде уже похоронили)


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


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


А не сможет — ну, откатит лицензионную модель обратно.

qmake не похоронили, я задавал вопрос в комментариях к статье на blog.qt.io про переход Qt6 на cmake (там как-то не совсем понятно это было сформулировано), меня заверили, что речь идет исключительно о переходе на cmake сборки самого Qt, а qmake для сторонних проектов в Qt6 никуда не денется. Ну а в целом да, статья несколько алармистская, я считаю. Даже если сделают форк, не факт, что это будет так уж плохо. Сейчас у Qt развитие идет главным образом в сторону embedded, automotive и так далее, в общем, в коммерческом направлении, все остальные направления идут как бы по остаточному принципу (пример — формат AAB появился еще в 2018 году, а поддержку его в Qt добавили только в 5.14, который вышел в декабре 2019). Может быть, если его таки форкнут, новые фичи будут бодрее реализовываться и в областях, касающихся, скажем так, более широкого круга разработчиков. Ну а HTML/CSS в браузере по сравнению с QML — это ИМХО такое… Как ниже правильно написали — Электрон с PHP на борту.
Богатый набор всего на свете. Тогда Qt воспринимался как boost с человеческим лицом, т.е. вещь в которой можно накопать всё что угодно и это будет работать хорошо и быстро.

Пересечение с бустом там так себе. Как в Qt называется аналог boost.graph или fusion?

Да конечно — выбираем самые нестандартные части boost и ищем это в Qt.
Все таки надо смотреть базовые части. Там пересечений довольно много. Например сериализация, работа с файлами и т.п.
Я скорее про то что Boost by design сборник разных библиотек не связанных друг с другом. А Qt таки фреймворк где взаимосвязанность сильно больше.
И тут фраза «секс, наркотики и рок'н'ролл» меняется на «наркотики, наркотики, наркотики»…
К сожалению, Qt всё дальше отстает от апстрима С++. На дворе 2к20й а людям всё ещё надо доказывать что smart-pointer'ы это хорошо и правильно (и нет, в Qt6 их не будет, будем как в 90х делать parent-child на raw-поинтерах).
Всякие std::optional/std::variant завезут только в 6ке и тоже непонятно когда и куда (у TQtC явно не хватает рук да и те разбегаются).
К сожалению, Qt всё дальше отстает от апстрима С++.

Ну как раз апстрим взял то, что в Qt было очень давно: variant, future, thread, smart-pointers и многое другое.


На дворе 2к20й а людям всё ещё надо доказывать что smart-pointer'ы это хорошо и правильно (и нет, в Qt6 их не будет, будем как в 90х делать parent-child на raw-поинтерах).

QPointer, QAtomicPointer, QSharedPointer and QWeakPointer — не то?! См. вики: https://wiki.qt.io/Smart_Pointers. Появились гораздо раньше, чем аналоги в C++!

Они то там есть, только весь фреймворк пронизан передачей и работой с обычными указателями. Ещё и этот parent-child… Если используется как библиотека для каких-то отдельных плюшек, то ещё не заметно. Но вот когда в качестве GUI фреймворка, то все время глаз дергается, что есть простой указатель, за которым кто-то приберет (или не приберет?)
Я както задумался, и пришел к выводу, что нету другого простого способа управлять ресурсами в Qt модели не через parent-child. Ну например, хотите вы сделать обертку над тредом, что-нить типа такого
class ThreadWrapper {
    virtual void run() = 0; // Этот метод будет запущен в потоке
    void start() { // Запуск потока }
    ~ThreadWrapper() {
           // Остановка потока
     }
}


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

Как эту проблему решить не через parent-child?
Перестать делать классы-потоки, тем более которые участвуют в иерархии?) Воркер-пулы на всё, а где все таки нужен класс-поток (уж явно единичные случаи) и можно без наследования обойтись.
Решается через некий ThreadManager, который сам позовет виртуальный метод stop у всех потоков. Менеджер можно даже синглтоном сделать, в котором каждый ThreadWrapper регистрируется при создании. Если других задач менеджеру не давать, то вполне рабочий вариант. Но и руками не забывать перед удалением stop говорить (собсна тот же std::thread развалится, если позвать деструктор, когда тред ещё работает, здесь даже попроще выйдет интерфейс, ну или совсем если мудрить, то в пользование отдавать всем простейший враппер над вашим тредвраппером, который в деструкторе будет звать у тред стоп и его деструктор)
Тогда QObject и signal-slot перестанут уметь в многопоточность
И притом совершенно непонятно ради чего будет эта потеря
В принципе, через ThreadManager можно и QObject-ы с signal-slot-ами работать. Как-то задумывался над этим, но не пробовал реализовать
Я понимаю, что это всё старое наследие… будем ждать в общем. Qt штука хорошая, местами есть нюансы, но это везде так. Лучше многих и часто лучше велосипедов. Да и я бы не сказал, что текущая ситуация с указателями прям сильно всё портит.
Система parent-child используется во многих UI (я даже не припомню таких, которые её не используют). Она логически напрашивается. Есть в окне панелька, в которой лежат кнопочки. Логично выходит, что панелька дочерняя к окну, а кнопки дочерние к панельки. Бывает, что на этой системе и отрисовку в рендере строят: рисуют от родителя к детям (как в Qt — не знаю). Причём она гарантирует, что кнопочка не отрисуется под панелькой, на которой лежит, а также что не придётся иметь геморрой с Z-порядком (по крайней мере в рамках родителей и детей). Убийство от родителя к детям тоже считаю полезной особенностью: при уничтожении окна не требуется обхода всех детей. Кроме того, QPointer всегда позволит знать, кто убит, а кто нет (если требуется).
Ну как раз апстрим взял то, что в Qt было очень давно: variant, future, thread, smart-pointers и многое другое.


std::variant имеет очень отдаленное отношение к QVariant (и вообще, QVariant это скорее std::any). И пришел он в стандарт из буста а не из Qt.
Аналогично, thread — тоже из буста.
Насчет указателей не уверен, но они появились задолго до стандарта в tr1 и скорее всего пришли в Qt оттуда (просто комитет тогда был слоупоком и не принимал их).

QPointer, QAtomicPointer, QSharedPointer and QWeakPointer — не то?!

Они там ест но даже новый код пишется без их использования, например, QThread::create который возвращает голый указатель на созданный тред. Каждый раз когда я использую этот метод, я его заворачиваю в unique_ptr.
Или например тредпул который берет раннаблы с булкой «надо ли удалять раннабл» (autoDelete), что приводит к рейсу, который описан в документации (кек). А всего-то надо передавать шаред_птр на раннабл — и булка не нужна и рейс уходит.
Из всех smart pointer в самой Qt активно используется только QPointer. Что мешает пойти дальше и начать использовать остальные указатели — яхз.
Или например тредпул который берет раннаблы с булкой «надо ли удалять раннабл» (autoDelete), что приводит к рейсу, который описан в документации (кек). А всего-то надо передавать шаред_птр на раннабл — и булка не нужна и рейс уходит.

А можно по-русски пожалуйста и с примером в целях повышения образованности? :)

Я не очень умею выражать свои мысли, поэтому давайте пример=)
setAutoDelete(false) нужен для того, чтобы переиспользовать раннаблы несколько раз. Например, мы хотим запускать раннабл дважды:
auto tp = QThreadPool::globalInstance();
auto run = new Runnable(); // класс наследует QRunnable и что-то исполняет
run->setAutoDelete(false); // хотим переиспользовать
tp->start(run); // запустили первый раз
tp->start(run); // запустили второй раз
run->setAutoDelete(true);
/* а вот так^ делать нельзя, потому что пул мог уже 
обработать раннаблы и не успеть прочитать булку. Это поведение
описано в документации, "пожалуйста, не стреляйте себе в ногу"*/



Теперь тот же юзкейз на shared_ptr:

auto tp = QThreadPool::globalInstance();
auto run = std::make_shared<Runnable>();
tp->start(run); // запустили первый раз
tp->start(run); // запустили второй раз

Фишка в том, что мы получили тот же юзкейз и нам эта булка вообще не нужна, нам нужен атомарный счетчик ссылок на раннабл. Если в пуле лежит 2 раннаблы, объект будет жив пока не исполнится последняя. Если мы держим ссылку вне пула, то тоже всё хорошо — пул ничего не удалит, а просто выкинет свои копии указателя.
Кода меньше, код безопаснее, нет corner-case'ов которые надо описывать в документации. Одни плюсы.
Спасибо за загрязнение персонального словаря новым приставучим термином 8)

Давайте только писать bool'ка или B00Lка, чтобы показать свой пацанский характер ))))

и нет, в Qt6 их не будет
в смысле?
Всякие QScopedArrayPointer и QSharedPointer — есть уже чёрти сколько лет.
Да, иерархия QObject использует сырые указатели — но там дерево объектов само отслеживает время их жизни, т.е. по сути является smart pointer'ом; добавлять туда ещё — это во многом бесполезное дублирование функциональности.

Обычно авторам таких высказываний неважно — как только обнаружен код без smart pointer'ов, делается вывод про качество всей библиотеки. И не интересует ни её объем, ни исторический (и надо сказать прекрасно себя показавший) подход к разработке — когда используется гарантированно поддерживаемый всеми компиляторами минимальный остов языка, ни устоявшиеся API с сырыми указателями… Надо smart и все тут, даже если это последий пункт в очереди болящих вещей.

Я так стараюсь придерживаться разумного минимума. На данный момент считая таковым C++11. Например, у Убунты LTS срок жизни пять лет, 16.04 C++17 по штату не положен. Недавно пришлось обновлять вполне рабочую систему на Debian из-за старой версии CMake. Но это сборка, а вот в готовом продукте необходимости обновиться или ставить левые зависимости заказчик может не понять (как и C++98). Я так понимаю, что скоро у нас будет три версии Qt — 4, 5 и 6. Впрочем, ЕМНИП, и третья довольно долго жила бок о бок с четвёртой.
Автор такого высказывания активно принимал участие в обсуждении перепиливания parent-child на умные указатели. И аргументов типа «сломается много кода» там нет, аргументы там были «да посмотрите вон на модуль ХХХ (вроде что-то с Xml) он написан на смартпоинтерах и там такооой говнокод». Изменение почти неломающие (кроме ряда случаев), старый код продолжает работать и копилироваться, но мы не будем его внедрять просто потому что мы в 2к20м не уверены что смарт поинтеры это хорошо. Это дословно аргументация противников, можете почитать development mail list.
А все же — какую проблему планировали решить данным proposal'ом?
И аргументов типа «сломается много кода» там нет
До этого даже не дошло мб?
А все же — какую проблему планировали решить данным proposal'ом?

Абсолютно неочевидная передача владение в куче случаев. QMainWindow::setCentralWidget репарентит виджет. QAbstractItemModel::setModel не репарентит модель несмотря на абсолютно аналогичное название.
QLayout::addWidget репарентит виджет.
QMenu::addAction не репарентит экшн.
Глядя на сигнатуру\вызов метода невозможно понять, передается владение или нет, что ведет к постоянным багам (не все смотрят в документацию каждый раз).
Хорошо если метод называется takeItem, можно угадать что он отдает овнершип юзеру… Но если юзер не догададется, получим утечку.

До этого даже не дошло мб?

Почитайте рассылку, там реально аргументы уровня студента (причем не от самих кутешников, а от каких-то рандомов)
QMenu::addAction не репарентит экшн.
И это правильно — один и тот же QAction может легко быть использован во множестве мест, в том числе и для ShortCut'ов, работающих везде в программе.
QAbstractItemModel::setModel
Нет такой.
Если вы про QAbstractItemView::setModel, то там тоже прямо сказано — одна модель may be shared between several views.
Глядя на сигнатуру\вызов метода невозможно понять, передается владение или нет
Вот это стоит исправить — сделать разные языковые конструкции для случаев когда владение забирается и когда просто даётся для использования.
Да, конечно же я имел ввиду вью, спасибо=)

Никто не говорит что это неправильно — это неочевидно при чтении кода. Код должен быть самодокументируемым и читающего не надо заставлять лезть в документацию, чтобы ответить на вопрос «нет ли тут утечки».
Примеры с addAction тривиальны, но есть места где приходится реально углубляться в чтение.
На самом деле, QLayout::addWidget гораздо лучше смотреть как пример. Я вот написал что он виджет репарентит, а на самом деле, он репарентит его не всегда, а только если лайаут чему-то назначен. Если у вас есть лайаут, ни к чему (ещё) не привязанный, вы сделали layout->addWidget(new Widget) и внезапно решили выйти из функциии (ну, например, настройки не считались)… Упс, утечка.
Да, это сомнительный corner-case, но его можно было бы избежать, использовав умные указатели.
не все смотрят в документацию каждый раз
В этом и проблема. В документации Qt всегда прописано, что владеет объектом.
Мне понравилось, как написал 0xd34df00d в своей статье — в C++ постоянно нужно вдумчиво писать код, на каждой строчке предвидеть возможные последствия и UB. Ну починят «проблему» сырых указателей в Qt (с которой живет сам фреймворк и тонны софта на нем), так ведь все равно C++ предоставит кучу способов сделать рокет-джамп выстрелить себе в ногу.
И аргументов типа «сломается много кода» там нет, аргументы там были «да посмотрите вон на модуль ХХХ (вроде что-то с Xml) он написан на смартпоинтерах и там такооой говнокод».
Если вы про вот это обсуждение — то там как раз всё в аргументах именно про «сломаются типичные паттерны использования» и «нам надо запилить свои смарт поинтеры для этого».
Куда остает?
У Qt6 в планах C++17, минимальный поддерживаемый компилятор на винде MSVC 2019 (не уверен какой конкретно версии).
Внутри уже давно на стандартные смартпоинтеры переписывают.
Строки по умолчанию хотят utf-8 сделать и прочее, прочее
Многопоточка никак не завязана на parent-child, вся иерархия «в треде» должна иметь нулевой parent (нельзя переместить в тред только часть иерархии, вы получите ворнинг).
Потом, никто не предлагает убирать иерархию, предлагают реализовать ее через unique/shared_ptr (и там уже есть счетчик слабых ссылок (а точнее вся дата QShared/QWeakPointer) в QObject для QPointer'а, например)
Смотрите: в Qt есть типовой use-case: если удаляем родителя, то должны умереть его дети. Это вполне логичное требование: если умерло окно приложения, то должны умереть и населяющие его компоненты. И кьют гарантирует что Вы сможете корректно это сделать даже в многопоточном приложении (путем наложения серьезных ограничений на эту многопоточность, но тем не менее). Как Вы собираетесь это реализовывать через unique/shared_ptr? Вообще какую пользу даст эта замена?
Как Вы собираетесь это реализовывать через unique/shared_ptr

Легко и изящно, parent-child отлично реализуется на unique_ptr (и можно даже сделать так что старый код будет работать).
0. QObject
1. TreemodelItem
2. Нода дерева

Вообще какую пользу даст эта замена?

Эта замена даст ту пользу что будет сложнее выстрелить себе в ногу (а сейчас сделать это ооочень легко) и передача владения будет явно выражена в коде:

window->setCentralWigdet(std::make_unique<QWidget>());

Да, с передачей владения через unique_ptr полностью согласен, это косяк Qt что до сих пор не реализовали
Надеялся, что Вы предложите вариант не Qt WebView и HTML/JS с аналогом таких элементов Qt, как мой любимый QTreeView и QGraphicsScene, а Вы PHP…
Кстати, LGPL в Qt появилась не сразу — сначала там была только GPL.
Я так сразу рванул делать на ней закрытое приложение по работе, поэтому сей факт хорошо помню, правда, уже не помню точно, когда это было, помню только, что давно.)
Во всём, как всегда, виноват Microsoft. Не сожри он Нокию, таких проблем бы не было.
Это для pet projects и больше замануха, вдруг выстрелит и опа — вы платите по $4K за лицензию: Qt for Small Business is restricted to companies with an annual revenue + funding of max $250 000.
Некисло так: $3950.00 в год. А потом ещё каждый год продлевать, пока программу распространяешь(или продаёшь).
Есть такая программка Yarxi. Разработчик её на Delphi написал. Собрал на краудфандинге 1500 евро на Delphi 10 Seattle. Его убеждали на Qt перескочить. Он устоял. Иначе бы вляпался в кабалу и пришлось бы словарик продавать по цене 2х Windows 10 major edition.
Не всё так адекватно для небольших компаний. Qt — это махровая коммерция для гигантов типа VAG и маленьким компаниям там делать нечего.
Иначе бы вляпался в кабалу и пришлось бы словарик продавать по цене 2х Windows 10 major edition.
Чем вам не нравится бесплатная LGPL лицензия?
LGPL это позволяет. Поэтому все с радостью встретили выход Qt 4.5 -где была добавлена эта лицензия
Что то Вы не договариваете, либо сами не разобрались с лицензиями.
Василий Иванович, что такое нюанс?
Видишь ли Петька:

Иначе зачем тогда работают менеджеры и юристы в Qt Company?

Веб? Интерпретатор вместо нативной программы? Нет, пожалуйста, не надо, прошу! Нет!

Ну когда они сменили Qt WebKit на Qt WebEngine в 5.7, сломав отличную разметку в Assistant и вывод на печать через QPrintPreviewDialog из QWebView (многие делали отчёты на html), это очень не понравилось многим разработчикам.
вот пример сломанной разметки

А какие вообще есть альтернативы QT, чтобы и интерфейс было относительно просто реализовать (приличный редактор форм, вполне вменяемая реализация взаимодействия между элементами интерфейса и остальным кодом), и реализации всякого полезного были (работа со списками, деревьями, потоками и т.п.), и чтобы все было единообразно, логично, вменяемо и кроссплатформенно?


Я пока что-то ничего не нашел. Разве что Delphi/C++ Builder, но оно уже давно тоже куда-то не туда смотрит, да и с поддержкой разных платформ как-то не очень по сравнению с QT.

UFO landed and left these words here
Ну почему, в некотором смысле аналоги есть. Те же GTK или wxWidgets. Но полноценного конкурента для Qt во всех его нишах (cross-platform desktop, embedded, mobile), думаю, нет. В его развитие очень сильно и долго вкладывались, и сделали реально мощную вещь, с которой непросто конкурировать. Поэтому и лицензирование такое — могут себе позволить, так сказать.
Qt — это не UI.
Qt — это огромный фреймфорв и UI в нём — это лишь одна из областей для которых он пригоден.
Widgets, QML и сопутствующее им половину всех dll и занимают.
А всему остальному замену найти как раз несложно.
UFO landed and left these words here
Вроде бы Word не использует mfc и другие библиотеки, которые microsoft даёт сторонним разработчикам, при этом он есть и под mac — то есть относительно кроссплатформенен, не все компании открывают свои наработки, а делают их только для себя, чтобы иметь конкурентные преимущества

ну, макофис может быть легко собран из другой кодовый базы (по крайней мере — UI). Можете провести анализ, какие компоненты они используют сами ?

UFO landed and left these words here
Господа минусующие, вы знак вопроса видите? Это вопрос был, а не утверждение. Если Джава не соответствует вопросу:
А какие вообще есть альтернативы QT, чтобы и интерфейс было относительно просто реализовать (приличный редактор форм, вполне вменяемая реализация взаимодействия между элементами интерфейса и остальным кодом), и реализации всякого полезного были (работа со списками, деревьями, потоками и т.п.), и чтобы все было единообразно, логично, вменяемо и кроссплатформенно?

Может объясните — почему, если уж настолько не согласны, что ставите минус?
Мы тут для embedded-проекта сравнивали Qt и JFX,… если кратко, это только на бумаге они конкуренты. Qt заводится с полпинка, среда ставится элементарно, документация нормальная, на арме не тормозит, поддержку аппаратного ускорения отрисовки имеет… Ничего из этого нет в jFX. В дополнение к этому, экосистема и комьюнити вокруг jfx практически нулевая, по сранению с Qt, а уж в области embedded тем более.
Embedded в условии не было. Было бы глупо ожидать производительности нативного c++ фреймворка от виртуальной машины Джавы. Они конкуренты разве-что на десктопе.
по сравнению с Кьюти это просто боль и страдание. Зато контролы нативные, но больше плюсов нет, все остальное минусы.
Я тоже так всегда думал, пока не увидел вот это видео, оказалось там не всё так плохо.
www.youtube.com/watch?v=FOIbK4bJKS8
www.youtube.com/watch?v=FwUGeV2fnfM

Хотя я всё равно буду использовать Qt, мне она кажется логичнее и удобнее.
По сравнению с Qt — у других библиотек плохо с документацией.
Qt этим берёт, не просто перечисление методов, а примеры правильного использования!
Но её делал Жасмин Бланше и Саммерфилд, которые уже давно ушли, и как мне показалось в QML документация уже не такая качественная.

Там не всё так плохо для задачи «сделать, чтобы была кнопка и она работала». А вот задачу сделать красивую программу, со всякими там стилями, темами и анимациями wxWidgets тупо не тянет. Функционально оно не уступит Qt, но вот визуально — очень.
JavaFX прекрасно работает на декстопе, и можно делать сильно навороченные вещи. Но не сильно быстрые (((
Я пока что-то ничего не нашел. Разве что Delphi/C++ Builder, но оно уже давно тоже куда-то не туда смотрит, да и с поддержкой разных платформ как-то не очень по сравнению с QT.
1. Он как раз таки смотрит куда нужно в последние наверно лет 7+ :)
2. Каких платформ не хватает?
3. Существует полностью бесплатный FPC/Lazarus, который работает как говорят, хоть на утюгах :)
1. Скорость на Делфе примерно 10% ниже плюсов на Windows, тут спорить не буду. Опять же есть Билдер, который шустрее.
2. За счет нативного кода ниже шарпа скорость не может быть никак.
3. На мобильных платформах и Линуксе/OSX сборка в Delphi и Билдере идет с помощью LLVM, поэтому скорость сопоставима с другими срадами собирающими бинари LLVM'ом
Ой ли. Вот тут можно взять исходники и проверить. FPC там почти вдвое медленнее С (с шарпом у автора какие то нелады в системе — лучше сверять у себя).

Шарп уже умеет компилиться в нейтив, кстати.
Встроенный Делфи копмпилятор всё таки пошустрее FPC. Но тут есть нюанс: FPC умеет собирать бинари с помощью LLVM тоже на некоторых платформах и вот можно было бы попробовать разные варианты. В FPC пошли дальше Делфи — в качестве бэка сборки можно юзать и свой компилятор и LLVM и JVM и сборку в JS (вот как раз пишут). Думаю, что и на другие платформы будет LLVM бэк дописан, FPC очень активно развивается в последнее время.
wiki.freepascal.org/LLVM
Раз в пару лет пробую поставить Lazarus, собрать проект по умолчанию (с одним пустым окном) и всегда компиляция падает на каких-то странных ошибках(
Что пишет то хоть? :) У нас вот проекты под миллион строк работают без каких-то особенностей и на винде и на линухе.
Хех, сейчас поставил на чистую убутнту 18.04, и… все работает, ура! Кажется, раньше я пробовал это всё на винде, хотя не помню, несколько лет уже не проверял.
Зависит от того, какая версия в репе лежит. Мы ставили Лазарь уже на примерно семи разных сбороках Линухов, fpcupdeluxe удобнее.
  1. Проблем несколько.
    Во-первых, глючные до безобразия IDE после версии 5.5.
    Во-вторых, перенос проектов на новую версию IDE может превращаться в серьезную проблему в случае использования сторонних визуальных компонентов. А порой и без использования оных можно получить проблем в полной мере (один переход на Unicode чего стоил, долгожданный, но, как именно его сделали...).
  2. Во-первых, среда разработки только под Windows. Для меня это уже серьезный минус.
    Во-вторых разработка под некоторые платформы не просматривается, в то время как Qt там основной вариант (тот же Sailfish).
  3. Lazarus, конечно, вещь интересная, даже пользую его иногда, но это совсем не Delphi. Это даже до версии 5.5 по удобству не дотягивает. Особенно "радует" необходимость пересборки всей IDE при добавлении визуальных компонент.
1) Юникод уже более десяти лет назад был, все компоненты перенесены и очень давно. Я сам три проекта примерно около млн строк перенес на уникод полностью за примерно неделю вместе с компонентами, вот примерно в 2010м году, да. По стабильности — сижу на XE6, работает неделями без единого сбоя. Да, проблемные версии были, они известны. Не обязательно их использовать.
2) Если не нравится Delphi которая действительно только под Win, то Лазарус в помощь, он работает 'по месту', сам постоянно в Линуксе на нем сижу.
3) Пересборка идет довольно шустро, примерно 15 секунд вся среда с компонентам пересобирается и их можно ставить 'пачкой', особых сложностей это не доставляет
К слову — пилят подобие bpl в Лазаре. Так что текущее состояние не на всегда. Смогут копмоненты устанавливаться точно так же как в Delphi.

1) Тем не менее в целом с обратной совместимостью проблемы были чаще, чем в Qt. Да и сторонних визуальных компонент, для которых не появлялись обновления под новые версии Delphi, очень много встречалось.


Еще вспомнился один занятный баг, который хорошо попил крови. При попытке сборке одного проекта под более новыми версиями Delphi, чем исходная 2005, на которой проект разрабатывался, постоянно получали странную ошибку. Что-то вроде "Internal error" с каким-то кодом. Причем никаких объяснений именно по данному типу ошибки нигде не было, по месту возникновения ошибки ничего понять не получалось.
Уже спустя несколько лет попыток таки собрать проект под новыми версиями Delphi случайно где-то в сети обнаружили упоминание, что в этом случае надо просто везде заменить object на class в объявлении классов. Что интересно, хватило изменения только в том модуле, при компиляции которого выдавалась ошибка.
3) У меня в 15 секунд не укладывается. обычно несколько минут. Впрочем, это не сильно меняет ситуацию. Пока по всем параметрам, определяющим удобство использования, до Qt ему далеко.
Хотя для "домашнего" пользования уже вполне годится.

Вы как-то все в прошлом застряли :) 5.5, 2005, уже как-то 15-20 лет прошло… Указанные проблемы уже настолько давно остались в прошлом — несовместимости какие-то, что их уже все забыли. Все более-менее заметные компоненты, которые стоит себе в проект вообще добавлять уже очень давно переработаны под новые среды.
Вы как-то все в прошлом застряли

Это просто самые яркие впечатления.
Впрочем, последние версии (после XE5) я действительно не пробовал, как-то совсем разочаровался к этому моменту. Может быть и зря, конечно.
Впрочем, желание попробовать последнюю версию производитель сам тут же убил в зародыше. Требовать телефон (без его указания просто не пустило дальше) за скачивание Community Edition — это как-то слишком.
А Qt пока за бесплатную версию не требует никаких персональных данных.

Кстати о lazarus, Qt для fpc оказывается есть. Интересное кино. Надо посмотреть-попробовать.

Когда-то Борланд делал Kylix. Там был набор виджетов от qt (через него работали компоненты — CLX назывался набор), но он был очень скромен по сравнению с delphi.
В какой-то версии ядра (уже не помню точно)- немного сменили формат elf файлов и kylix перестал работать, а его приложения требовали патча.
Всё так. Говорят что Майкрософт сильно вмешалась, после чего Kylix свернули, так бы мы уже очень давно имели нормальную кросс-платформенность. К сожалению Майкрософт всегда Делфе очень сильно гадил. В последнее время наконец они опомнились )
Врядли, качество куликса было неок, и самое главное что линуха на десктопе в пределах погрешности — бабок от продажи 0.

А что насчет ну к примеру связки flutter + rust? Вроде как те же яйца, но на более новых технологиях.

Кто б сомневался, что и тут будут Rust рекомендовать :) Вроде как автора вполне себе С++ устраивает. Но это безусловно намного лучше, чем выбор PHP :)
Флаттер ни под десктоп, ни под веб пока ещё не очень то юзабелен. Даже начальных релизов ещё не было, мастер только тащить. Только под Мак альфа вышла, насколько помню.
Последний раз, когда пробовал его, даже примеры из SDK были поломаны и не собирались. Так что, до Кьюта ему ещё долго ползти.

Хм, ну запилят очередной Qt на php (или чем то другом), кончится все тем же — как только начнется массовое использование придут эффективные менеджеры и опять начнут требовать деньгу.

Прочитать столько интригующего текста, что бы напороться на PHP…

Забыл добавить, юзать ab для бенчмарков это моветон, он часто бывает сам тормознее тестируемого кода.

Немного слов в защиту. Хотелось обратить Ваше внимание, что все государственные структуры в настоящее время переводятся на AstraLinux, где это связка c++/qt доступна прямо из коробки. Это факт как раз может послужить к увеличению количества разработчиков именно на этой связке. Если я не ошибаюсь то разработка ПО для госструктур должна выполнялся на сертифицированных средствах.

Вы уж извините, но в госструктуру я пойду в последнюю очередь=) Я лучше выучу rust или go (да даже php вспомню!) чем буду писать на уютной кутешечке на государство=)

А что, давно загран получали? Я подглядел в софт, в котором заполняли данные и фотографировали — Qt под KDE , если мои эльфийские глаза не окутаны каким-то волшебством. Вопрос работы в госорганизации холиварный, но код на Qt кое-где точно есть, и это в целом хорошая новость как по мне!

Судя по заказам на Upwork, большинство проектов десктопных приложений заказчики ожидают видеть на C#, WinForms. Qt очень редко нужен под Windows, чуть чаще под Mac и практически никогда под Linux.
Кроссплатформенность Qt конечно отличная штука, но далеко не всегда она нужна.
Вот и получается, что если начнут закручивать гайки в Qt, можно перебраться на C#.
Qt очень редко нужен под Windows, чуть чаще под Mac и практически никогда под Linux.

Очень спорное утверждение: как раз чаще всего на Линуксе — это и IoT, и embedded (что чаще всего) и Qt Automotive. Про Андроид вообще молчу: количество сильно растёт. Все проекты, на которых я работал на Qt (медицина, инжернерно-технические, управление временем и т.п.) были кросс-платформенные. Вообще отказ от Qt был бы катастрофой и замена его на Web или C# в большинстве проектов просто нереальна!!! Вот например в таких: https://github.com/mavlink/qgroundcontrol/ Это бред!

Вот и получается, что если начнут закручивать гайки в Qt, можно перебраться на C#.

Как человек который пробовал и то и другое, поверьте: с C# будет так плохо что лучше уж web-интерфейс. По производительности C# не тянет, при скрещивании C++ с C# возникает жирный промежуточный слой CLI, плюс логика реализации C# приложений радикально отличается от логики Qt приложений что в завязке на ситуацию когда вызовы могут ходить туда-сюда порождает совершенно нечитаемую логику приложения в целом (если в C++ есть какая-то логика а не набор отдельных вызываемых для скорости алгоритмов). Ну и WPF после QML — это очень больно и грустно.
Пока читал, — ждал появления простого и элегантного кода биндинга php в C++. Типа либа обёртка которая может «фсё искаропки», включая многопоточность и прозрачный обмен данными между потоками C++ и PHP, ч-з очереди.

Который жутко тормозит в сравнении с C++/Qt/QML.


Qt vs. JavaFX: https://www.youtube.com/watch?v=Kh6K-yEp_JY


HTML5 vs Qt: https://www.youtube.com/watch?v=Z4CwVN9RRbE


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

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

Что ты называешь "адеватным" сообществом? Ты хочешь сказать, что Java будет быстрее C++?! Даже комментаторы там признают, что C++ производительнее. Подтверждаю на собственном опыте: когда-то хотел сделать программу на Java но UI и расчёт ИНС тормозил на ней жутко — в 2-3 раза (хотя может надо было наплевать с прицелом на будущие перспективы и уровень зп ;) ) — сделал на C++/Qt.


С видео о HTML5 в комментариях и лайках вообще ни у кого вопросов не возникло. Чтобы спорить здесь надо быть полным неадекватом.

  1. Мы всё еще о UI или вы из тех, кто вычисления в одном потоке с интерфейсом делает?
  2. Цифры относительно «тяжелых» вычислений и «высокой» скорости, конечно де у вас под рукой?
  3. Про большинство приложений тоже интересно увидеть цифры
  4. Про видосы, как уже сказали ниже — без кода — это мусор.
  1. UI, вычисления у нас конечно в отдельном потоке.
  2. Конечно: см. пост выше: Java была в 2-3 медленее на моих задачах
  3. Большинство приложений, где используется Qt: https://en.wikipedia.org/wiki/Qt_(software)
  4. Статья выше — это мусор или ты хочешь сказать, что JVM или HTML5 будут работать быстрее нативного кода C++/Qt? О чём здесь речь вообще?! Какие тебе цифры надо?

Ну кстати в теории же html + js по такой же схеме работают как и qml + js. И там и там язык разметки плюс клей из js.
Просто qml намного лучше задизайнен. А вот javafx увы, не сможет тягаться никогда, у нее сам рендер тоже на джаве, он никогда не будет столь же быстр как нативный.

Ну кстати в теории же html + js по такой же схеме работают как и qml + js. И там и там язык разметки плюс клей из js.

"В теории", а на практике, когда скорости JS начинает не хватать — переносишь логику в C++ и всё начинает летать на порядок быстрее — проверял. Ну и "разметка" в QML — это нативные C++ объекты QML Items с аппаратным ускорением, так что они тоже сильно быстрее HTML.

Я думаю htmlные теги тоже в итоге мапятся на нативные обьекты, да и логику же тоже можно писать в плюсах и прокидывать в вебню. По крайней мере, так точно можно было в QtWebKit делать

В QML можно реализовать любой новый элемент на плюсах, унаследовав его от QQuicklItem, если он визуальный, или просто от QObject, если нет, и легко и просто интегрировать его в остальной QML код. А вот как реализовать подобным образом кастомный html тег — я что-то сходу даже и не знаю.

Я как-то задумывался над реализацией UI на WebKit. Кастомный html тег не нужен. Идея была в следующем:
На html+css+js делаем типичный веб UI (не исключено и использование популярных в js фреймворков). Далее делаем интерфейс C++ -> js. В QtWebKit это выглядело как C++ класс на одной стороне и аналогичный js объект на другой. Ну так вот, через этот интерфейс все данные и таскаем.

"Кастомный html тег не нужен" напоминает мне анекдот про "потребности в колбасе на сегодня нет". А если мне нужен именно визуальный компонент? Что мне толку с этого js объекта, если я не могу его отобразить? Мне придётся корячиться и пытаться лепить что-то на js стороне из DOM объектов. А с QML я на C++ стороне его нарисую именно так, как мне надо, хоть через scenegraph, хоть через QPainter, да и все. Быстро, просто, экономично в плане ресурсов.

А, вы в плане вставки кастомных компонентов. Это да. Сам сейчас копаю сей вопрос. Теоретически можно (всякие Flash в своё время так и встраивались со стороны браузера), но явно не просто
можно было

Но ведь не сделано, правда? :) Или вы предлагаете аналог Qt с нуля написать?! :)

По хорошему, сейчас можно смотреть в сторону WASI, wgpu и всего такого. Все вместе это смогло бы вырасти в куда более универсальное и прикольное решение.
Можно языки разметки типа qml напрямую в wasm транслировать, а с хоста прокидывать нужные методы.

Блин, самой либе уже 30 лет, это вот прямо говоря, очень много, очень очень. То, что они запускаются внутри wasm это круто, но они при этом тащат огромный техдолг вовнутрь.

Ну и что, что либе 30 лет? Все эти 30 лет она развивалась. Если вы сейчас начнете что-то новое велосипедить, то паритета по фичам достигнете еще условно через 30 лет, и то если Qt все это время будет стоять на месте. Это не говоря уж о том, что веб — это всего лишь одно направление для Qt из многих, потому что веб подходит не всегда и не всем.
касательно
когда скорости JS начинает не хватать — переносишь логику в C++

Есть надежда что WebAssembly позволит точно так же, но в html

Ну у WASM-а скорость уже будет сравнима с Java или C#, до C++ всё равно будет недотягивать.

И для некоторых вроде меня явная нелюбовь разработчиков Qt к QВиджетам вызывает неприятные ощущения под спинным мозгом.
Может дело в прямоте рук? Вон intellij idea на swing работает шустро, а это более старая технология.

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

Согласен, что IntelliJ тормоз. Кстати, борландовские гуевые среды просто реактивными кажутся по истечению стольких лет...

С другой стороны с kdevelop сравнивать сложно, потому что на моём плюсовом проекте он падает при индексации, а clion — не падает.

Там им в комментах написали, что даже для rpi3 интерфейс сильно тормозит.
Немного не профессионально. Мало того, что там видео заминусили, так вы сюда тащите этот шлак как аргумент.
Вы бы еще видео Антона Полухина здесь запостили.
Давайте с примерами, того, что можно запустить у себя на машине. Я начну.

Вот, скачайте(не надо выбирать онлайн) и кликните самый большой датасет. Поиграйтесь, посмотрите на зумы и прочие фишечки.
А потом вернитесь и покажите мне такой аналог на плюсах, но чтобы не тормозил.

dlsc.com/products/flexganttfx
Вообще странно. Люди, которые пишут на плюсах должны быть максимально объективны.
Ведь это те самые локомотивы, что двигают прогресс.
Они как никто другой сталкиваются с проблемами, которые скрыты от какого-нибудь среднего разработчика.
И они как никто другой, должны понимать, на сколько сложно объективно измерять перформанс.

Но смотришь на комменты и некоторых индивидов и диву даешься.

Ведь сам javafx писан на плюсах, как и JVM. И те плюсовики, которые пишут JVM, от них редко услышишь подобного рода заявления. Ну то есть люди, которые создают продукты, которые реально двигают миллиардные бизнесы по миру.
А тут приходит «Вася из Ульяново» и рассказывает, как же джава тормозит, аж скулы сводит.
Без аргументов, без цифр, без примеров, без замеров. Человеческий фактор.
А тут приходит «Вася из Ульяново» и рассказывает, как же джава тормозит, аж скулы сводит.

Можно вопрос из зала? Вот смотрите. Есть чудесный проект Кассандра. Как известно, он на Джаве. Но его зачем-то переписывают на C++ — ScyllaDB. Если джава прекрасно, то зачем так делают? Все-таки, значит, есть проблемы в джаве и с перформансом, и с выделением памяти. И ребятки решили бороться с этим самым радикальным методом. Нет? Это не означает, что "джава тормозит". Это реально миф из бородатых времен. Но возможно, что есть типы задач, которые лучше делать тут, а другие типы задач — там.

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

С такими очевидными вещами никто и не спорит. Вот питон реально медленный, тут мало что попишешь, но даже у него огромная ниша. Особенно в связке со всякими плюсовыми либами.
У переписывания, может быть 1000 непонятных причин. Java с 1.6 прекрасно работает с нативной памятью и имеет достаточно нормальную интеграцию с С++.

Сложно представить, что проблемы с performance, которые возможно затрагивают 1-5% кода, нельзя оформить доп. нативной библиотекой. А какой-нибудь менеджмент вообще не про performance.

Я подозреваю, основная причина все-таки embedded и AOT, который Java никак не расдуплится сделать с другими фишками типа Canadian Cross.
Сложно представить, что проблемы с performance, которые возможно затрагивают 1-5% кода, нельзя оформить доп. нативной библиотекой

Во многих приложениях это UI — 1-5% кода, а 95% делом занимается а не формочками :). И если на плюсах начинает жить логика (а это очень часто так для подобных приложений) то всё, хана, интерфейс быстро разрастается и становится непонятным, так что оказывается в разы проще UI на плюсах сделать. И в случае с Qt это вдобавок получается очень удобно, просто в разы удобнее того же C#. По части удобства какой-нибудь мелкой разработки где язык работает клеем между С++ библиотеками, на мой взгляд рулит Python. Там хорошо прототипы пишутся по принципу «все медленное пихаем в плюсовую библиотеку, всю логику оставляем в Python, для UI прикручиваем PyQt». С Java правда не работал (если не считать написания небольшого плагина для ImageJ) но по отзывам слышал (да и мне самому так показалось) что он плюс-минус на C# похож.
Тут вроде про DB разговор, там UI вообще нет, но тонны код по оптимизации, парсингу и т.п., а ядро базы данных где нагрузка 99%, в БД-проектах где-то 10% максимум.
Про «типичный» проект говорить нельзя, но, конечно, же UI -кода в 10 раз больше, чем backend.

Конечно, я же и говорю, вы платите железом например. Ну и FFI здесь не единственная проблема. Урезанные версии джавы запускали на симкартах вроде. Но когда вы пишете на десктопной джаве, то как правило пишете разухабисто, с объектами, вот это все.
Трейдофф

У джавы больой throughput но малый latency. Я так понимаю это фундаментальный момент всех гц. Плюс джит на эмбеддед так себе надо полагать

У Java максимальный throughput при заданном железе, но если надо гарантировать 95% заданной скорости, например 10 мс на http response, то это не работает.
Потому что, 1) JIT — который пока раскочегарится и соберет статистику 2) GC — может выпадать в ненужные моменты.
По сути если мерить кол-во http response в 1 минуту на заданное железе, то throughput будет одинаковый или лучше. А вот хвост 5-15% самых медленных запросов, будет гораздо хуже.
в видео демки запущены на дохлых планшетиках. что вполне соответствует панелькам в промышленности или автомобильных
В целом flutter очень близок к qml, и гугл обещает выкатить связку flutter + dart под desktop, может и отожмет какую то часть рынка у Qt.
Проблема в том, что Qt можно легко интегрировать с другими библиотеками на C++, а у флаттера будут проблемы.
это да, в целом у fluttera проблемы что пока что всего очень мало, но конкуренция это всегда хорошо. Я рад за это
В целом flutter очень близок к qml
Идеологически может и да, а по синтаксису сильно хуже :/
Что еще ждать от Qt?! Они уже пару десятилетий не могут пофиксить корректную работу путей в windows, содержащих нелатинские символы.

Поэтому по моему лучше форк (тем более, если KDAB готов вписаться), чем полных отказ от Qt и переход на Web, что есть полнейший бред для многих задач!

Как может форк решить лицензионную проблему с мобильными приложениями, про которую писал автор поста?


Кстати говоря, а каким пунктом LGPL создана такая проблема?

не встретил проблем, да там обрабатывать надо иначе, но это точно не критикал

Недавно встал выбор библиотеки для проекта, который должен быть «кросс». Выбор был между Qt, Java и «чем угодно ещё». Java не очень люблю (субъективно, хотя на 13 уже можно существовать), к тому же нужно было в любом случае писать код на плюсах для критичной к быстродействию части, а JNI — боль, так что его отбросил почти сразу. В Qt сомневался, поскольку не очень хорошо отзывались мои сотрудники о нём. В итоге погуглил, и понял, что у меня есть минимум ещё 2 варианта — SDL и wxWidgets. Присмотрелся ко второму (соблазнило использование нативных системных компонентов), и понял, что это «оно». С системой layout разобрался достаточно быстро, с быстродействием проблем нет — ибо native. С лицензированием глубоко не вкуривал, но вроде тоже всё спокойно.

Пытался написать на wxWidgets десктоп приложение лет десять назад. Количество плохо документированных функций, непонятных багов ( когда нужно делать именно так а не иначе чтоб работа ) просто поражаеет. Не знаю улучшились ли они за эти годы, но тогда это был плохой выбор.

Не знаю, может, мы с разработчиками «нашли друг друга», но в документацию пришлось вкуривать всего пару раз, на неочевидных названиях контролов и на тонкостях работы с OpenGL (адепты Вулкана — молчать, сам о нём знаю, но для первого прототипа юзал что умею). Остальное кодил на интуиции, и оно работает как задумано.

О, автор, прямо на больную мозоль!
Я недавно сам озадачился этим вопросом и решил перейти на что-то близкое, желательно, что-то на C++. Хотел начать для себя разрабатывать большое приложение на Qt, хотя многое в Qt не нравилось — монструозность, проникновение не только в GUI, но и в логику, отставание от стандарта. Изменения в политике Qt стали последней каплей. Основное требование к новому фреймворку стала открытость, ± нативность на Linux и простота разработки.


Путём исключения дошёл до GTK+ (gtkmm). На нём Gnome написан, если кто не знает. Так вот, язык может и хороший, но инструментальная обвязка — тихий ужас. Я попытался запустить проект Hello World по умолчанию из их среды разработки Builder IDE — не получилось с трех раз!!! Попытался запустить Glade (инструмент разработки UI для GTK+) — Glade упал. Добавить к этому почти полное отсутствие поддержки Android. В общем, отказался я от него.


Решение пришло неожиданно. Обнаружил для себя GUI-фреймворк Kivy для python. Простейшую программку для него я набросал за время компиляции hello world для gtk. И я влюбился в kivy. Это реально простой GUI-фреймворк, построенный на sdl2. У него есть собственный простой язык разметки интерфейса (аналог qml) — kv (сравните с многословным xml-based у GTK+).


Пусть kivy, возможно, не подходит для production, пусть у него есть некоторые нелогичности в поведении, но мне он настолько понравился своей простотой и наличием неплохой документации, что я первый раз в своей жизни сделал донат и очень этим гордился. Уже месяц как пишу на киви, вижу кучу странных решений, но всё ещё очень им доволен.


Кстати, на хабре недавно вышла статья по библиотеке для kivy, адаптирующей внешний вид к android — kivymd.

Насчёт отставания от стандарта — да, Qt не на bleeding edge развития C++, но подвижки идут. Например, тот же новый (относительно, ему уже несколько лет) синтаксис сигналов-слотов на указателях на функции, или отказ от собственных алгоритмов в пользу STL. Опять же, чтобы понять путь библиотеки, нужно "обуть ее обувь" — фреймворк появился в годы черти какой поддержки стандартов, единственным выходом было использование минимального и гарантированно подерживаемого подмножества языка. С тех пор все изменения в пользу новых стандартов предпринимаются с учётом всех поддерживаемых платформ!
Насчёт проникновения не только в GUI, но и логику, как Вы говорите — все же Qt это фреймворк, он и не позиционируется как библиотека, поэтому все логично. Т.е. предлагается некий скелет, некий подход к организации приложения, следуя которому можно реализовать что-то удобно и комфортно. Если идти против его идеологии, боль неизбежна.

Я бы и продолжал пользоваться Qt для своих pet-проектов (я даже 2D-игру на нём начал делать), технические ограничения — не основная причина перехода. Хотя тут тоже такое. Пытался я сделать кнопку-иконку или кнопку с иконкой и текстом — не нашёл такого механизма из коробки, хотя это частый use-case. Но это так, не важное.


Что важно — это политика Qt в отношении сообщества. Захотят закрыть фреймворк — закроют, они продемонстрировали, что мысли в ту сторону у них уже имеются. А ведь другой представитель KDЕ сказал, что вряд ли они потянут форк Qt. И никто не потянет Qt — там слишком много экспертизы нужно, чтобы поддерживать и qml, и widgets, и moc, и кросс-платформенность, и qt core (QList, QString, ...).


А взять тот же kivy. Ну скажет автор, что закрывает код kivy. Так тут только одно русскоязычное сообщество сможет поддержать продукт — это же обертки на cython вокруг SDL + простой транслятор для kv. Совсем не rocket science. Поэтому для себя я замену нашёл. Я понимаю, что Qt гораздо больше, чем просто GUI, но я, к примеру, хочу свои pet-проекты программировать ради удовольствия, не беспокоясь, что завтра фреймфорк закроется.


P.S. Кстати, у kivy еще и довольно активное community, которое помогает. (это в тему про удовольствие)

Захотят закрыть фреймворк — закроют
Полностью — не могут. У них контракт с KDE, по которому они обязаны открывать код не позднее чем через год после его появления под коммерческой лицензией.
Если вы не смогли на qml сделать кнопку с текстом, то вы как то плохо в нем разобрались, уже 4 года пишу gui на qml и не было еще графического элемента который невозможно было создать, просто и легко. Так что QML прекрасен

Ну, во-первых, да, qml хорош. А не могли бы вы здесь продемонстрировать код на qml для кнопки с текстом и иконкой?

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

Button {
    Row {
        Image {}
        Text {}
    }
}


способов там тыща, в зависимости какую действительно кнопку вы хотите. Есть стандартаная кнопка из QtQuick.Controls
                Button {
                    text: "example"
                    icon.source: "qrc:/source.png"
                    onClicked: {}
                }

если хочется совсем свое, то можно как в конструкторе все построить через Item как базу
            Item {
                implicitHeight: childrenRect.height
                implicitWidth: childrenRect.width
                Row {
                    Image{}
                    Text{}
                }
            }

Те, кто говорят про icon.source (kanutah) не забывайте, что возможность эту добавили только 2 или 3 года назад, до этого никаких icon.source в стандартной поставке не было. А когда Qt 5 вышел? в 2013 году? И всё это время чего-то не хватало — то иконки не встроишь без костылей, то layouts ещё толком не завезли. Примерно об этом ниже и говорит Harrix. Сейчас, кстати, Qt5 более-менее юзабелен. Но на горизонте уже маячит Qt6 и возможное закрытие релизов на 12 месяцев.
Кстати, у меня этот ваш первый способ когда-то так и не получилось завести нормально. Вот я прямо сейчас его попробовал — на простом изображении он работает, а на иконке с высоким разрешением — просто не отображает её, отображает черный квадрат. Из моего опыта — метод есть, метод работает, но часто работает он не так, как от него ожидаешь. При сборке в тот же андроид, куча настроек слетают, иконки иногда даже простые не отображаются. Но это только мой опыт, а я не самый лучший программист.
Про использование Row. Вот мне приходилось примерно так и выкручиваться, чтобы заработало. Только ведь если вы используете Item, то вам надо и обертку писать, чтобы имитировать поведение кнопки.
Но вообще, как я говорил, техническая часть не является проблемой. Я и игру на Qt для себя писал, с картинками и анимациями там работал — проблем особых не возникло. Основная проблема — политика Qt Project. QtRoS пишет, что я недооцениваю сообщество, видимо полагая, что KDAB и сообщество сможет поддерживать форк. Поддерживать — сможет, а развивать? У них приоритетный проект — KDE, разработчиков на зарплате даже для KDE не особо-то много. А уж вытянуть команду, которая будет развивать целый фреймворк с двумя языками программирования (C++, QML), у них и подавно не получится.
В общем, для своих пет-проектов я выбор сделал. Мне лишний стресс не нужен, поэтому я отказался от Qt, несмотря на то, что Qt более продвинут, чем киви в любом из аспектов.

обертка для того чтобы сделать из Item кнопку это строчек 15-20 и потом юзаете на весь проект. А ваши проблемы выглядят как просто отрицание, если что мы вас не заставляем сидеть на qml, но и гнать на него надо
Те, кто говорят про icon.source (kanutah) не забывайте, что возможность эту добавили только 2 или 3 года назад, до этого никаких icon.source в стандартной поставке не было.

Ну сначала в Qt5 были Quick Controls 1, потом вышли Quick Controls 2. Идет постепенное развитие. Но QML тем и хорош, что у него очень мощные примитивы. По сути любую кнопку можно сделать, скомбинировав rectangle, image/text и mousearea. Ограничения практически отсутствуют.

Вот я прямо сейчас его попробовал — на простом изображении он работает, а на иконке с высоким разрешением — просто не отображает её, отображает черный квадрат.

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

Button {
    icon.source: "path/to/icon.png"
    icon.color: "transparent"
}

Я сейчас попробовал засунуть в кнопку изображение 4096x4096 (это же достаточно высокое разрешение?) — отобразилось нормально, по крайней мере на десктопе.

При сборке в тот же андроид, куча настроек слетают, иконки иногда даже простые не отображаются.

Ну, это странно. У меня есть несколько pet-проектов на Qt для iOS и Android, не сталкивался с чем-то таким. Ну точнее такое может быть наверное, если вы как-то хардкодите пути к картинкам вместо использования ресурсов, а картинки кладутся куда-то не туда, куда вы ожидаете, но в целом у меня как-то таких проблем не было, честно говоря.

Основная проблема — политика Qt Project

У Qt Company уже давно такая политика. Они постоянно балансируют между стремлением заработать денег и стремлением не потерять сообщество. И будут этим заниматься дальше. Такова их тяжелая доля. Устраивать по этому поводу истерики я бы не стал.
У Qt Company уже давно такая политика. Они постоянно балансируют между стремлением заработать денег и стремлением не потерять сообщество.

Вот поэтому я и решил сменить фреймворк. Пусть они себе балансируют, а мне нервы дороже. Я сменил фреймворк и очень этому рад. Киви в десятки раз хуже, чем Qt, но мне его функциональности хватает. Для меня главное — душевное спокойствие, которого с балансирующим Qt мне не получить.

Стандартная кнопка из Quick Controls 2 с иконкой и текстом под ней будет выглядеть примерно так:

Button {
    icon.source: "path/to/icon.png"
    text: "Button"
    display: Button.TextUnderIcon
}


Искаропки, естественно. Плюс ее можно дополнительно стилизовать. Ну а так да, способов просто миллион.
Закрытие фреймворка в эти дни эквивалентно форку, поэтому этот сценарий хоть и является неприятным, но не пугает.
там слишком много экспертизы нужно, чтобы поддерживать и qml, и widgets, и moc, и кросс-платформенность, и qt core
Мне кажется Вы недооцениваете сообщество. Люди коммитят в .NET Core, в Go, в VS Code, в K8S — там тоже многослойно.
Спасибо за наводку, но я тоже в своё время его пробовал, тоже понравилось. Пока не применил на Андроиде. Не знаю как сейчас, но тогда интерфейс прям вот очень заметно тормозил. Не то что медленно, а именно тормозил. Но я даже не про скорость, а про то, что такие вещи намекают на «зрелость» продукта. А так да — Kivy приятная штука.
В kivy всё прекрасно, но их сайт не открывается (спасибо РКН). И когда надо распространить результаты своего творчества, вы будите виселиться (виселица находится в конце деревни).
Статья кстати однобокая и алармистская полностью, про то что LTS платные он сказал, но ведь это не означает что Qt платный стал, просто все будут сидеть на одной dev ветке. Так что рано еще лить слезы по Qt

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

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

Это понятно, но это не ответ на мой вопрос.


PS. Qt под LGPL так же появилась не сразу, минимум лет 10 до этого Qt вообще была доступна только под двумя лицензиями: коммерческой и GPL.

Ну, лично я тогда относился к ней с осторожностью, потому что использовать по работе один фреймворк, а для себя — другой неудобно.
Вопрос не дурацкий. Нет, не только этим. Меня волнуют последствия и как это скажется на продукте. Если сейчас годами баги висят, то что там при политических пертурбациях дальше может получиться…
Если сейчас годами баги висят, то что там при политических пертурбациях дальше может получиться…

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


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


Соответственно, может быть движение в сторону зажимания гаек с тем, чтобы собрать больше денег, приведет к улучшению продукта?


PS. Сам я придерживаюсь точки зрения, что цена на коммерческую лицензию высоковата (раньше она была пониже). Но саму Qt следовало бы распространять всего под двумя лицензиями: GPL и коммерческой. По крайней мере в ситуации, пока Qt Group вынуждена сама зарабатывать на разработке Qt и не имеет богатого донора (как это было после покупки TrollTech фирмой Nokia).

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

Казалось бы, при чем тут IDE?


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


Так что критерии, которые могут применяться к IDE, вряд ли применимы к базовой библиотеке.

Согласен, некорректно высказался. В термин IDE я включал как и саму систему разработку, так и всю библиотеку Qt.

Так если говорить о Qt, то какой интерес Qt Group развивать бесплатную для чужих коммерческих проектов версию, если разработчики этих проектов не вносят достаточного вклада в развитие Qt?

Меня сейчас, наверно, заминусуют, но поймите меня правильно: я люблю Qt, но если есть на выбор вариант «просто использовать» или «использовать с обязательным условием вклада (денег, времени и т.п.)», я выберу первое.
И источник денег выберет первое.
Да, я могу править баги, писать свою виртуальную клавиатуру под Андроид, графики самостоятельно рисовать, чтобы «быть добропорядочным использователем библиотеки».
Но зачем мне это, если я просто могу использовать charts.js, отдать ему json из любого места, и пойти дальше?
Тут кто-то спрашивал про датагриды «не-Qt». Я вот специально в заметке указал, что я не буду в детали вдаваться, а то бодания начнутся до бесконечности. Потому что кому-то Ext JS надо, а кому-то onclick() на кнопку достаточно. И они друг друга понимать не будут. (Вон уже «Electron с PHP на борту» кто-то озвучил...)
Но именно там кроется одно из преимуществ веба: там всего — дофига и больше.

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

Но именно там кроется одно из преимуществ веба: там всего — дофига и больше.

Ну, на эту тему существует и альтернативное мнение, с которым я, в принципе, согласен. Это пока тебе надо наколеночную поделку сделать в три строчки, веб выглядит привлекательно, а нужно будет что-то посложнее — и приплыли, и бесплатные npm-пакеты, про которые так изящно выразился автор комментария по ссылке выше, не помогут. Лично я с пониманием отношусь к стремлению Qt Company зарабатывать деньги, причем зарабатывать деньги не за счет OpenSource-энтузиастов, которые, даже если и не контрибутят напрямую в проект, то все равно дают определенную рекламу и экспертизу — примеры использования, примеры решения типичных проблем, а за счет тех, кто в свою очередь зарабатывает деньги за счет каких-то своих закрытых продуктов, сделанных на базе Qt, это честно и справедливо, потому что на эти деньги фреймворк по сути и развивается. Их ценовая политика — это уже отдельный вопрос, как и то, что они основной упор делают на IoT, embedded, automotive и так далее, и в первую очередь пилят там, но, видимо, там сейчас основные деньги.
Стремление Qt заработать денег понятно, просто совершенно не ясно как игры с лицензиями и запретом на установку без аккаунта Qt помогут эти деньги заработать.
Есть мнение что никак, просто неэффективный менеджмент уже выдохся придумывать где денег заработать и делает рандомные действия ну вдруг поможет.
А вот такой вопрос про клавиатуру и графики — собрал я qt с ключом --opensource, клавиатура есть, графики есть. Я не могу их использовать, несмотря на то, что оно есть во вроде бы опенсорсной версии?
Можете, просто требования GPL 3 надо соблюдать.
Про Charts и Virtual Keyboard:
In addition, it is available under the GNU General Public License, version 3
И я еще присоединюсь к вопросу. Верно ли то, что если разрабатывать для ПК пользуясь opensource версией Qt и линковать его динамически (LGPLv3) или линковать его динамически и открывать исходники (GPLv3), написанное в статье не должно волновать?
Если вопрос только в деньгах — правильно.
Можете даже статически под LGPL, только с большей морокой, если законы соблюдать.

КМК, паниковать рано. В любом случае, либо будет форк под более либеральной лицензией под эгидой тех же KDE или KDAB. Либо QtC будет вынуждена более лояльно относиться к сообществу.
Я, честно говоря, за форк, так как QtC ударилось в Automotive, QML и прочий Embedded, хотя от Qt, чтобы соответствовать времени, требуется совсем другое: полноценный веб/мобильный тулкит. А вот у тех же KDE есть Kirigami и большой ряд других вещей в KDE Frameworks, которые неплохо было бы включить в новый форк.
А насчёт перехода на другой стек технологий варианты есть: wxWidgets, Electron+JS, gtkmm и другие. Но торопиться пока не нужно, с Qt всё будет хорошо.

Не приведи господи придется вам реализовать что-то, работающее с видео. Вещи, которые в Qt элегантно делались по щелчку пальцев с гарантированной работоспособностью, в варианте с вебом превратится в кровавую кашу.
Delphi/Builder в помощь. Один раз достаточно заплатить. Если профешшнал версию — то сильно дешевле чем Qt за год. Будете иметь и кросс-платформенность и несколько визуальных фреймворков и веб и так всяко.
Как вариант — FPC/Лазарус, тот вообще бесплатный.
Фреймворки работают прямо внутри IDE, в пределах одного языка, и не требуют каких-то связок как Флаттер.
После волны возмущения, QtC поменяли решение, LTS версии в свободной лицензии будут просто выпускать с задержкой в 12 месяцев.
Для меня — просто отличный вариант, если с багфиксами такой задержки не будет. Я на новые версии и так в течение года не лезу.
Привет!
Между прочим, есть и движение «с обратной стороны»: веб-стартапы, написанные на PHP, разрастаются и начинают требовать быстрых компонентов на C++

Благо возможностей в современном PHP вынести часть кода в C-библиотеку достаточно, а с каждой новой версией будет ещё больше. Так что, велкам!

Для меня показателен пример с TreeView. В Qt Quick Controls 2 отсутствовал такой базовый компонент, как TreeView. А в Qt Quick Controls 1 он был, но данный набор компонентов для QML получает статус deprecated. И много лет этот компонент не создавался, и соответствующий «баг» висел несколько лет.


И вот несколько дней назад данный «баг» закрыли. Я так и не понял: предложенное решение официальное или нет. Но в любом случае решение будет не в составе основного пакета, а через Qt Marketplace. И не до конца понятна лицензия, но комментарий «Wait is this GPL only? (╯‵□′)╯︵┻━┻» о многом говорит. Соответственно для MIT проектов компонента TreeView в составе Qt Quick Controls 2 не будет, и раз баг закрыт, то Qt и не будет даже об этом думать.

Подскажите где он в Qt Marketplace, я что то не нашел, в составе какого то пакета?

Пока только добавляется: "The request for TreeView into Marketplace is currently being processed, and will end up there soon. It will also be offered through Qt installer."

Поэтому, если нужно только десктоп разработка, то виджеты почти всегда предпочтительнее. Хотя они тоже условно deprecated (их никто не выпиливает, но и новых фич нет).
О да! Столкнулся с подобным в своём последнем приложении на Qt. По-моему, мне нужен был TreeView и MapView. Один был в одной версии контролов, а другой — в другой. Или, может, MapView был доступен в обеих, но в одной сильно урезанный по функциональности. Давно дело было.

В итоге я помучался, помучался, пособирал дистрибутив под мак ось бессонными ночами (ага, кросс-платформенность, но приложения еще и доставлять как-то надо) и в итоге написал все на вебе. Приложение у меня нетребовательное к ресурсам.
Интересно, какого размера будет Hello World при использовании связки C++ и PHP? И сколько мегабайт оперативки будет съедать простое приложение состоящее из одного окна и нескольких кнопок?
Допустим у меня есть CAD приложение, в котором GUI сделан на Qt. Как в нём можно заменить GUI на HTML/CSS/JS/PHP? Как это будет выглядеть? Каждая панель с кнопками это WEB-страница? Для каждого Message Box строится DOM, запускается интерпретатор и виртуальная машина?
Допустим у меня есть CAD приложение, в котором GUI сделан на Qt. Как в нём можно заменить GUI на HTML/CSS/JS/PHP?

CAD — понятие растяжимое. Если это что-то типа OnShape, т.е. нужно непосредственное немедленное общение с пользователем, то PHP тут вообще будет лишним.
Каждая панель с кнопками это WEB-страница? Для каждого Message Box строится DOM, запускается интерпретатор и виртуальная машина?

Нет, конечно.
Чисто кстати, Chrome DevTools Protocol принес с собой новый класс UI приложений: web + нативный бэкенд вроде go или nodejs. Раньше такие приложения строились как раз по модели «запускаем <любой веб фрэймворк> на локалхосте и открываем веб морду во вкладке браузера»
На полном серьёзе читал статью до самого PHP. Автор молодец: обычно либо сходу начинают пороть чушь и этим палятся, либо всё пишут серьёзно. А тут мы прямо пол-часа крутили педали, чтобы увидеть табличку «ха-ха, дальше пропасть». Отлично :)

О Qt всё давно понятно: им не интересны все эти ваши мелкие софтины на 3.5 пользователя. Им надо продавать Qt в какой-нибудь автомотив или томограф, так, чтоб покупатель платил за сотню лицензий разработчиков следующую сотню лет. К этому и идут. Каждый может сам себе решать по пути ему с ними в этом или нет.

На счёт UI автор прав, что лучше HTML и CSS ничего уже человечество не придумает. Qt до него не дотягивает, и QML не дотягивает, и WPF не дотягивает. А больше и нет ничего. Значит, будет везде HTML и CSS. Вопрос вот только в том, зачем нам в этой связке дальше Javascript и PHP. А они не нужны. Нужен WebAssembly (на плюсах, на расте), у которого будет доступ к DOM, CSS и всей инфраструктуре браузера(аудио, видео, сеть, камера и т.д.). И вот мы получаем чистый, быстрый, нативный код в комбинации с мощной системой отображения. Профит!
они не нужны. Нужен WebAssembly (на плюсах, на расте), у которого будет доступ к DOM, CSS и всей инфраструктуре браузера(аудио, видео, сеть, камера и т.д.). И вот мы получаем чистый, быстрый, нативный код в комбинации с мощной системой отображения. Профит!

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

wasm это не нативный код, а браузер сожрет свои 100Мб/страницу

пока что выглядит хуже альтернатив
Почему wasm — не нативный код? Вполне себе. Сколько там сожрёт браузер, мне совершенно не интересно. Если всё это закончиться тем, что код на плюсах что-то посчитает и сможет это показать в HTML без JS со всякими там его динамическими типизациями и GC, то меня это полностью устроит и по производительности, и по внешнему виду.
потому что wasm это байт код очередной виртуальной машины.

с таким уровнем знаний и аргументации я спорить не могу
Ой ну с определённой точки зрения всё, что выше уровнем, чем линия на осцилографе — можно называть «кодом очередной виртуальной машины». Посмотрите вон на Вики во что развернётся код, собранный в васм и скажите мне, чем эта «очередная виртуальная машина» виртуальнее обычного асма?

Да и дело никогда не было в виртуальной машине, а было в тормознутости парсинга текстовых форматов, динамической типизации, сборщика мусора и т.д. В васме всего этого нет.
Вернемся на 30 лет назад, и вспомним как был устроен Бейсик. Он что, от этого стал дико производительным ЯП???

Наличие GC (да и динамической типизации) ортогонально wasm — машине — есть реализации ЯП с GC, компилирующиеся в wasm =) Аллокатор все равно нужен.
Вы странные вещи говорите.
В мире, где уязвимо все, железо, софт, вы предлагаете рассылать пользакам голый бинарь?

Вы же понимаете, что это не возможно? В любом случае, в вэбе, как в недоверенной среде, будет что-то, что можно засунуть в какую-то обертку. И эта обертка и есть вирутальная машина.
Тут нет альтернатив. Но это не так уж и плохо. Джава достаточно быстрая\энергоэффективная для большинства задач. И в ВАСМ можно сделать не хуже.
Джава достаточно быстрая\энергоэффективная для большинства задач
Потому во многих областях от нее отказались =)

В мире, где уязвимо все, железо, софт, вы предлагаете рассылать пользакам голый бинарь?
Запускать бинарь в песочнице дешевле, чем крутить интерпретатор виртуального кода.
Вы только что жаловались на отсутствие аргументации и тут же сами эту аргументацию опустили.

Вот вам аргумент номер 1, дальше можно даже не ходить.
У пользователя может быть абсолютно не определенное железо.
Арм, РИСК5, МИПС, х86, под все будем один мультибинарь делать?
Или каждому пользаку будем рассылать под архитектуру его проца?

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

Джава например компилится в рантайме и местами очень даже не плохо.
Васм это байт код, и его интерпретация и дальнейшая компиляция в нативный код происходит достаточно быстро, чтобы не заморачиваться на этом.
Отставить эротические фантазии! Тесты потребления памяти Явы есть у меня в публикациях.
Джава например компилится в рантайме и местами очень даже не плохо.
Даже весьма неплохо, если вы можете подождать пару минуток старта на суперсервере.
А про риски, писки, мипсики я бы сначала проверил.

Ой, а память вы завезли грузовиком?

"А про риски, писки, мипсики я бы сначала проверил."
Ага, отлично. Давайте не будем думать наперед. Ведь таких проблем у человека ещё не было. Хотя уже сейчас их как минимум 3, где количество девайсов уходит за сотни миллионов.
По факту решения этой проблемы у вас нет, кроме попыток не очень удачно иронизировать.


Про память…
Там где нужен васм, проблем с памятью больше нет. На телефонах нынче и 16ГБ ставят. 4ГБ сейчас минимум на самых дешёвых устройствах.


Не увидел ни одного аргумента.
Вот вам мой. makepad.nl
Текстовый редактор, васм, летает у меня на телефоне aarch64 и на компе amd64.
В нативной версии без васм, не оставляет и надежды всяким vscode

На телефонах нынче и 16ГБ ставят. 4ГБ сейчас минимум на самых дешёвых устройствах.
Производители одобряют. А то некоторые так пишут, что и на полгиговом устройстве всё работает.
Сути это не меняет.
Вы не сможете это никак обойти.

Сэндбоксинг, разные архитектуры и проче, прочее.
У вас выбор не слишком велик. Придется идти на компромиссы.
И они, по сравнению с голым веэбом(CSS+JS+HTML) выглядят очень и очень многообещающе.
Это понятно. Если б Нокию не сожрали, всё могло бы сложиться иначе, но увы. Придётся раз в два года телефон менять.
N900 still in my heart.
После него, были сильные ломки на счет перформанса всего вот этого андроид мира.
Диковато было наблюдать, как до этого 600MHz и 256 озу могли держать полноценную вытесняющую многозадачность как на десткопе, на каких-то адских техпроцессах умудрялись жить примерно столько же и на микро аккуме в 1300mah.
А потом характеристики начали расти как на дрожжах.
А скайп тормозил все сильнее и сильнее.

Понимаешь, что мир немного пошел не туда. И ничего с этим поделать нельзя.
Но ничего страшного, покуда человек разумен, рано или поздно мы начнем думать про перформанс.
Так же как и про корону, когда упремся в потолок.
Это заложено в нас генетически. Идем по пути меньшего сопротивления.
Не так эффективно как могли бы )))
Ну, на N950 их уже сделали. Правда, Qt Widgets убили, но это уже Microsoft. А на N900 зато был стилус. Каждый раз, когда приходится что-то делать на морозе (у нас тут, чай, не Калифорния), его вспоминаю. Впрочем, кроме зума из жестов я ничего не использую, может, поэтому так.

Да, перепутал — я имел ввиду n950.
После него Андроид с его «кнопками» доставлял жуткие неудобства

Да, это удивительно, ибо только сейчас более-менее жесты пришли в андроид.
Хотя жизнеспособность концепции была проверена лет 10 назад.

Все, которые одним пальцем, работали прекрасно. И мне как-то хватало.
Даже была попытка реализовать что-то похожее на двухпальцевые жесты (тот же зум). И оно даже как-то работало почти на уровне "можно пользоваться".
Упомянутый wholeman стилус и сейчас есть в некоторых аппаратах, но зато N900 можно было зимой спокойно пользовать пальцами в обычных перчатках, а не в каких-то специальных.

Ну, двухпальцевые всё же работали криво.
У N900 стилус был обычной палочкой с тоненьким кончиком, а сейчас это либо сосиска, либо что-то специфическое, некоторые вообще заряжать надо.
В перчатках тоже, но экран был маленьким, поэтому в них далеко не всегда было легко попасть. Наверное, частый кейс — ответ на звонок, там кнопки большие, но я обычно отвечал с гарнитуры, поэтому было неактуально.
Там где нужен васм, проблем с памятью больше нет.
То то не затихает плач, что браузер выжирает всю память. Или васм нужен не там?

Посмотрел, wasm дает потери по скорости от 50% до 150% от натива. Плюс накладные на JIT машину (память).
На хабре тоже есть цифры оттуда, чтобы долго не смотреть видео.

Неплохо конечно (лучше JS), но ничего особенного. Выигрыш относительно JS легко объясним строгой типизацией и ручной аллокацией.
То то не затихает плач, что браузер выжирает всю память. Или васм нужен не там?

Ну тут уже началась подмена. Как вы думаете, сколько сейчас сайтов на васм?
Пользаки сейчас плачут не над васмом очевидно.

Неплохо конечно (лучше JS), но ничего особенного.

Не надо верить на слово или полагаться на чьи-то слова.
Откройте какой-нибудь gmail, в соседней вкладке makepad.nl и сравните память. Отличается на порядок.
Можно ли это назвать «но ничего особенного»

Вы слишком не объективны и эмоциональны в этом вопросе.
То исследование мир уже видел, и даже там conclusion такой:
«We identify the causes of these performance gaps, providing ac-tionable guidance for future optimization efforts.»

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

JIT машину (память)

JIT это больше не про память, а про ЦПУ. Это по сути отложенные оптимизации, которые вы обычно делаете АОТ.
В случае АОТ знатно потребляется как память так и ЦПУ. Но в случае джита это не совсем так. Ибо, у вас могут быть участки, которые никогда не оптимизируются за ненадобностью.
Пользаки сейчас плачут не над васмом очевидно.
Конечно они плачут не от васм, но в той области
Там где нужен васм, проблем с памятью больше нет.
Я теряю логику ваших высказываний.
Проблема с памятью в браузерах таки есть.
Откройте какой-нибудь gmail, в соседней вкладке makepad.nl и сравните память.
Сравню, когда будет две страницы со схожей функциональностью. Эти очевидно несравнимы.

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

Видно, что теряете. Проблема в браузерах есть. Но вы не ищете источник этих проблем. Для вас важно доказать утверждение браузер=говно.
Потому, что только это утверждение, с которым никто никогда не спорил.
Но оно слишком поверхностное, чтобы это обсуждать на таком уровне.

Эти очевидно несравнимы.

Ну раз для вас это вызывает трудности, то я умываю руки. Можете считать, что я слился )

UFO landed and left these words here
Если вы не поняли, речь идет про эмбедед vs носимые у нас в карманах «суперкомпьютеры».
И телефон с 4ГБ рам за 8тр, сейчас норма. Так что не вижу с чем вы тут спорите.
Учитывая, что эти цифры растут уверенными темпами.

Ну и васм, по сравнению с современным вэбом памяти потребляет столько, что этим можно пренебречь.

Ну, пример с hello world, допустим, работает.
А возьмём реальное приложение. Где куча форм, контроллов, полей и т.д.
На qt — накидал в композере, обозвал — и дальше хоть на С++, хоть на python — оно просто работает. На маке, винде и линуксе.
А вот теперь вдруг захотелось, чтобы все эти контролы были в веб-приложении.
И так же всё летело и свистело, где надо.
Нажал клавишу в поле, ткнул мышкой в контрол или график — и на бэкэнде получил нужный сигнал/коллбэк, как будто это на десктопном приложении. Правильно среагировал, что нужно поправил — и оп-па, на фронтэнде то, что нужно, автоматом перерисовалось/отреагировало.
Тут уже достаточно очевидно, что статической странички, которую на сервере сгенерит php как в вашем примере и отправит — явно недостаточно. А на стороне пользователя интерактив подразумевает скрипты. Явно не на php, а на чём-то, что есть прямо сейчас под рукой, прямо там. Тут-то что делать?
И есть ли фреймворки для веба, чтоб так же накидать визуально контролов на форму, а потом по клику в браузере на кнопку тупо вызывался обработчик ON_CLICK в бэкенде, без всяких подробностей, как это "унутри" работает, но с возможностью туда углубиться, если вдруг что-то пошло не так?

В вебе фреймворков хватает на любой вкус и цвет. И как мне кажется, в описанной автором ситуации лучше бы подошел не PHP, а node с с изоморфным приложением.
Не уверен, что правильно понял вопрос, но если это вообще про «как начать», то можно даже без фреймворков для простых панелей обойтись.
Просто: 1) делаете API на запросах/ответах. В этой заметке, где про простые интерфейсы и про «много посчитать», для этого предлагается PHP. Если в API предполагается много мелких простых запросов, лучше смотеть на что-то типа Swoole.
2) а на страничке вешаете что-то такое:
horse_color_button = document.getElementById("horse_color_button");
horse_color_button.onclick = function() {
    $.ajax({
        url: "/api/version/horse_color",
        data: {
            ...
        },
        success: function(result) {
            ...
        },
        error: function(result) {
            ...
        },
        type: 'POST'
    });
    return false;
};

Можно даже без jQuery.
Для «посложнее», как справедливо заметил oxidmod, фреймворков много.
А есть аналоги для embedded (embedded уровня одноплатников типа rpi)? Пробовали сравнить с OpenJFX — последняя дико тормозит, т.к. при использовании без иксов вся отрисовка там софтовая, а qt летает, потому что использует OpenGl (На самом деле не все так очевидно, потому что тестировали в том числе и на beaglebone black, у которого OpenGl, вполне возможно, не был доступен ни тому приложению, ни другому).

У Beaglebone Black так-то стоит PowerVR SGX 530. Да, тормоза, но в сравнении с Broadcom VideoCore IV все не так плохо. Стоковые сборки Qt обычно таки линкуют с поддержкой OpenGL

Да, вероятно, в демках Qt была часть с каким-то легким 3Д, и она летала. А в JFX даже курсор мыши заметно отставал от самой мыши.
Лет 10 я так или иначе использовал связку C++/Qt, последние пару лет ушел в другое направление, но за трендами развития любимого фреймворка слежу, да и есть всякие пет-прожекты, которые пишу или поддерживаю на этом стеке.

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

Но сейчас ребята, во-первых, поплыли в узкие специализации типа automotive, поэтому во фреймворке все реже и реже появляется что-то вкусное для обычного разработчика. Во-вторых, все, что появляется, имеет либо коммерческую лицензию, либо GPL. И иногда это прям супер абсурдно: Qt Network под LGPL, а Qt Network Authorization под GPL ¯\_(ツ)_/¯
Или, например, ребята делают неплохую штуку — Qt Http Server, могло бы расширить использование фреймфорка для веб-разработки, но тоже под GPL. Кому оно в таком виде нужно будет?

При таком раскладе кажется, что функционал фреймворка заморожен. Либо используй то, что уже давно есть, либо плати. И я бы без всяких проблем с удовольствием поддержал бы проект и купил для своих пет-проджектов коммерческую лицензию, если бы она стоила не космических $3950 на разработчика в год! Откуда они вообще такие цены взяли? В чем проблема сделать инди лицензию $10 на разраба в месяц, без платной поддержки и прочих сомнительных «плюшек»?

А все это, как кажется мне, губит как экосистему Qt, так и плюсов. Мало того, что на пятки плюсов наступают современные, более простые и безопасные языки (go в бэкенде, rust в системщине и т.д.), так еще и старые, проверенные временем инструменты вставляют палки в колеса. Зачем разработчику садится учить Qt, если завтра он опять поменяет политику лицензий, либо компания не сможет его потянуть по цене? А зачем учить плюсы, если можно что-то быстренько набросать на всяких веб-технологиях, как предлагает автор поста (а потом эти приложения жрут гигабайты памяти и тормозят)? В итоге может получится ситуация, когда только большой интерпрайз типа VAG и будет сидеть на фреймворке, пока кто-нибудь и там не решит его поменять на что-то другое. Ну, так и приходят концы таким проектам.

Что же, будем надеяться, что все будет хорошо, они как-то выправят свою политику лицензий и цен. Форк от KDE — это, конечно, хорошо, но, кажется, поддерживать большую кодовую базу Qt как минимум сложно и ресурсоёмко.
Для KDE и прочего не автомобильно/иотного/мобильного последнего актуального LTS ещё на десяток лет вперёд хватит. Достаточно будет бэкпортить фиксы на явные баги

А в чем проблема с qt http server? GPL 2 и 3 не обязывает открывать исходники если все крутиться на ваших серверах.

В конфликте лицензий, например. Я вот хочу разрабатывать свой опенсорс проект под MIT лицензией, если просто Qt в зависимости я могу добавить то, GPL-онли компонент уже нет. Любой cover work тоже обязан поставляться под GPL лицензией. Если бы требование было просто «обязан открыть исходники» то куда ни шло…

Мне почему то это напомнило ситуацию с qnx, тоже была система для своего времени крутая. И также менеджмент загубил компанию… Интересно, продают ли ее сейчас. В некоторых вакансиях на Qt, проскакивает QNX, но это все оборонные предприятия

При продаже Qt, Матиас Этрих (основатель КДЕ) остался в Nokia, видимо что-то знал...

А как быть, если все таки хочется использовать open source версию Qt для своих закрытых android приложений(в том числе коммерческих)? Как мне предоставить возможность пересборки с другими версиями Qt? Достаточно ли будет фразы в духе «если хотите пересобрать приложение с другой версий Qt, то напишите мне на почту» и по запросу высылать портянку инструкций вместе с make, obj и другими файлами?
В моём скромном понимании, по электронной почте по запросу нельзя (если только продукт не распространяется по электронной почте или с письменной офертой). Продукт, лицензия, инструкции и исходники должны быть из одного публично доступного источника, либо должно быть чётко написано где скачать вышеуказанное. И это место должно быть доступно пользователю пока действует лицензия.
Как раз по запросу и надо. Так вас обязывают предоставлять это не всем подряд, а только официальным пользователям (если у вас коммерческое ПО).
Опять-таки, в моём скромном понимании (а оно такое у всех, потому что GPL специально так написана):
В п.4e LGPL указано на предоставление интрукций методом п.6 GPL.
При распространении через Play Store, смотрим в GPL на п.6d. Так что всё-таки без дополнительных запросов надо обеспечивать.
Если не через Play Store, я сделал оговорку в скобках выше.
На сервере может быть пароль на вход, или личный кабинет чтобы убедиться что пользователь получил ПО именно от вас. Ведь если он получил его не напрямую от вас, то и GPL обязательства к нему у этого третьего лица а не у вас. А если вообще не получал а сразу хочет исходников — то GPL вас вообще не связывает и не обязывает.
На сервере может быть пароль на вход, или личный кабинет чтобы убедиться что пользователь получил ПО именно от вас
Да, если распространялось ПО таким же образом.
If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) that supports equivalent copying facilities
В сторе андроида без ввода пароля тоже ничего не купить, так что эквивалентно.
Просто Elsedar про «напишите мне на почту» говорил. А это вряд ли эквивалентно.
А если ПО распространяется сразу на железяке, какие там equivalent copying facilities?
Я честно пытался разобраться в этих лицензиях, но я и на русском едва ли могу такие тексты читать, а на английском еще быстрее теряюсь.

Т.е. если резюмировать, то можно выложить эти инструкции(вместе с бинарниками), например, на своем сайте, а ссылку на сайт указывать внутри приложения и в его описании на Play Store?
Я понимаю именно так. Только ещё про упоминание на видном месте лицензии, и на что она распространяется, не надо забывать.
Спасибо, что помогаете разобраться.

А, если учитывать, что apk файл по сути zip архив, в котором лежат Qt модули в виде *.so файлов, то снимает ли это обязанность дополнительно публиковать свои бинарники? Ведь у конечного пользователя уже есть все необходимое для замены Qt модулей.
only to the extent that such information is necessary to install and execute a modified version of the Combined Work

Т.е. если в инструкции указано как поменять LGPL-компоненты внутри (чего бы то ни было, что вы распространяете), то этого достаточно при динамическом связывании.
Спасибо!

В общем, за пределами десктопов LGPL 3 – это большой геморрой очень неудобная лицензия, а про магазины приложений я даже и начинать не буду...

Тогда получается, что все не так уж и плохо с магазинами приложений?
Тогда получается, что все не так уж и плохо с магазинами приложений?

Тут серая зона. Вы не можете гарантировать, что кто-то из потребителей вашего приложения не будет использовать его устройстве, где заблокирована ручная установка из APK? Можно ли заставлять пользователя в таком случае публиковаться на Play Store? Что, если третье лицо (Google) откажет ему в публикации? И т.д. и т.п.
Ну так и на десктопе никто не может гарантировать, что потребитель приложения не будет «использовать его на устройстве, где заблокирована ручная установка» — например, административными средствами.
Тут не в устройстве дело, а в модели распространения.
На десктопе (в обычном понимании) приложение ставит сам пользователь, без посредников, значит подразумевается, что у него есть права и на то, чтобы повторить это с изменённой версией.
работоспособность после замены dll никто не гарантирует.
Приложение Qt если ему подсунуть dll другой версии Qt просто будет падать (хоть вроде там и обещают заменяемость, но видно она не всегда срабатывает).
Обычно с чем компилили с тем и распространяют.

Автор смешал две разные проблемы:


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

Первая проблема, как здесь уже неоднократно писали, решается переходом на Delphi. Но эту проблему не нужно решать, если принять во внимание вторую.


А здесь всё хуже. Лично я считаю, что на текущий момент веб-приложения принципиально не могут достичь того комфорта для пользователя, который могут обеспечить десктоп-приложения. Все эти трюки, которыми делается "как-бы-десктоп-ПО", трюками и остаются. На десктопе оконная система нативная, в вебе она эмулируется стилями и манипуляциями с DOM. На десктопе программа имеет полный доступ к оборудованию, в вебе — если только повезёт с браузером. Десктоп-приложение может работать в отсутствие сервера, а для веб это скорее исключение.


Но, с другой стороны, веб создаёт возможности, которых у десктопе не было — запуск без установки, не нужны обновления на машине клиента, единая серверная авторизация, единое место хранения данных без передачи клиенту коннекта к БД… Платная подписка на сервис, конечно же.


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


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

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


Но общая идея в целом правильная, только надо, чтобы исполняющие модули (здесь Qt) не передавались с сервера вместе с приложением, а были встроены в браузер.

Рост спроса на веб и мобилы, и, по факту, отсутствие решений для этого со стороны Qt

Про веб не скажу, а под некоторые мобилы это как раз основной способ разработки.
Да и под андроид вроде уже очень даже работает.

Я работаю в основном с PHP и эта статья для меня как бальзам) Спасибо
Для Делфистов статья тоже до какой-то степени бальзам :) Мы то всегда знали, что бесплатный сыр — он только в мышеловке. Очередное подтверждение.
Как в том анекдоте — «Лозунг-то гарный… цiль погана». Заменить десктопное гуй приложение вебовским с неизвестно откуда взявшимся сервером на пыхе… ну так себе альтернатива. Особенно если приложение — системная утилита, например.
Есть такая штука — java. Производительность как у си, нативная переносимость без перекомпиляции и совершенно офигительный UI framework. Не говоря уж о сотне других фреймворков на все случаи жизни.
Only those users with full accounts are able to leave comments. Log in, please.