How to become an author
Search
Write a publication
Pull to refresh

Comments 306

Основная проблема всего написанного в том, что это лишь один кейс использования 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, так что программисты будут его учить, т.к. он перспективный и т.д. и т.п.


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

Total votes 31: ↑31 and ↓0+31
qmake не похоронили, я задавал вопрос в комментариях к статье на blog.qt.io про переход Qt6 на cmake (там как-то не совсем понятно это было сформулировано), меня заверили, что речь идет исключительно о переходе на cmake сборки самого Qt, а qmake для сторонних проектов в Qt6 никуда не денется. Ну а в целом да, статья несколько алармистская, я считаю. Даже если сделают форк, не факт, что это будет так уж плохо. Сейчас у Qt развитие идет главным образом в сторону embedded, automotive и так далее, в общем, в коммерческом направлении, все остальные направления идут как бы по остаточному принципу (пример — формат AAB появился еще в 2018 году, а поддержку его в Qt добавили только в 5.14, который вышел в декабре 2019). Может быть, если его таки форкнут, новые фичи будут бодрее реализовываться и в областях, касающихся, скажем так, более широкого круга разработчиков. Ну а HTML/CSS в браузере по сравнению с QML — это ИМХО такое… Как ниже правильно написали — Электрон с PHP на борту.
Total votes 6: ↑5 and ↓1+4
UFO just landed and posted this here
Да конечно — выбираем самые нестандартные части boost и ищем это в Qt.
Все таки надо смотреть базовые части. Там пересечений довольно много. Например сериализация, работа с файлами и т.п.
Total votes 2: ↑2 and ↓0+2
UFO just landed and posted this here
Я скорее про то что Boost by design сборник разных библиотек не связанных друг с другом. А Qt таки фреймворк где взаимосвязанность сильно больше.
Total votes 1: ↑1 and ↓0+1
И тут фраза «секс, наркотики и рок'н'ролл» меняется на «наркотики, наркотики, наркотики»…
Total votes 14: ↑14 and ↓0+14
К сожалению, Qt всё дальше отстает от апстрима С++. На дворе 2к20й а людям всё ещё надо доказывать что smart-pointer'ы это хорошо и правильно (и нет, в Qt6 их не будет, будем как в 90х делать parent-child на raw-поинтерах).
Всякие std::optional/std::variant завезут только в 6ке и тоже непонятно когда и куда (у TQtC явно не хватает рук да и те разбегаются).
Total votes 16: ↑9 and ↓7+2
К сожалению, 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++!

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


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

Как эту проблему решить не через parent-child?
This comment wasn’t rated yet0
Перестать делать классы-потоки, тем более которые участвуют в иерархии?) Воркер-пулы на всё, а где все таки нужен класс-поток (уж явно единичные случаи) и можно без наследования обойтись.
Решается через некий ThreadManager, который сам позовет виртуальный метод stop у всех потоков. Менеджер можно даже синглтоном сделать, в котором каждый ThreadWrapper регистрируется при создании. Если других задач менеджеру не давать, то вполне рабочий вариант. Но и руками не забывать перед удалением stop говорить (собсна тот же std::thread развалится, если позвать деструктор, когда тред ещё работает, здесь даже попроще выйдет интерфейс, ну или совсем если мудрить, то в пользование отдавать всем простейший враппер над вашим тредвраппером, который в деструкторе будет звать у тред стоп и его деструктор)
Total votes 4: ↑4 and ↓0+4
Тогда QObject и signal-slot перестанут уметь в многопоточность
И притом совершенно непонятно ради чего будет эта потеря
Total votes 2: ↑2 and ↓0+2
В принципе, через ThreadManager можно и QObject-ы с signal-slot-ами работать. Как-то задумывался над этим, но не пробовал реализовать
This comment wasn’t rated yet0
Я понимаю, что это всё старое наследие… будем ждать в общем. Qt штука хорошая, местами есть нюансы, но это везде так. Лучше многих и часто лучше велосипедов. Да и я бы не сказал, что текущая ситуация с указателями прям сильно всё портит.
This comment wasn’t rated yet0
Система parent-child используется во многих UI (я даже не припомню таких, которые её не используют). Она логически напрашивается. Есть в окне панелька, в которой лежат кнопочки. Логично выходит, что панелька дочерняя к окну, а кнопки дочерние к панельки. Бывает, что на этой системе и отрисовку в рендере строят: рисуют от родителя к детям (как в Qt — не знаю). Причём она гарантирует, что кнопочка не отрисуется под панелькой, на которой лежит, а также что не придётся иметь геморрой с Z-порядком (по крайней мере в рамках родителей и детей). Убийство от родителя к детям тоже считаю полезной особенностью: при уничтожении окна не требуется обхода всех детей. Кроме того, QPointer всегда позволит знать, кто убит, а кто нет (если требуется).
This comment wasn’t rated yet0
Ну как раз апстрим взял то, что в 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. Что мешает пойти дальше и начать использовать остальные указатели — яхз.
Total votes 6: ↑6 and ↓0+6
Или например тредпул который берет раннаблы с булкой «надо ли удалять раннабл» (autoDelete), что приводит к рейсу, который описан в документации (кек). А всего-то надо передавать шаред_птр на раннабл — и булка не нужна и рейс уходит.

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

Total votes 2: ↑1 and ↓10
Я не очень умею выражать свои мысли, поэтому давайте пример=)
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'ов которые надо описывать в документации. Одни плюсы.
Total votes 2: ↑2 and ↓0+2

булка — это что в данном случае?

Total votes 2: ↑1 and ↓10
boolean, bool, вот эта сама bool autoDelete()
Total votes 2: ↑2 and ↓0+2
Спасибо за загрязнение персонального словаря новым приставучим термином 8)
Total votes 2: ↑2 and ↓0+2

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

This comment wasn’t rated yet0
Не за что, держите еще один — батарея (QByteArray)
Total votes 5: ↑5 and ↓0+5
и нет, в Qt6 их не будет
в смысле?
Всякие QScopedArrayPointer и QSharedPointer — есть уже чёрти сколько лет.
Да, иерархия QObject использует сырые указатели — но там дерево объектов само отслеживает время их жизни, т.е. по сути является smart pointer'ом; добавлять туда ещё — это во многом бесполезное дублирование функциональности.
Total votes 7: ↑7 and ↓0+7

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

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

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

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

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

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

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

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

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

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

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

Иначе зачем тогда работают менеджеры и юристы в Qt Company?
Total votes 3: ↑1 and ↓2-1
Текст лицензии LGPL доступен. почитайте, там всё написано
Total votes 4: ↑4 and ↓0+4

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

Total votes 30: ↑28 and ↓2+26
Ну когда они сменили Qt WebKit на Qt WebEngine в 5.7, сломав отличную разметку в Assistant и вывод на печать через QPrintPreviewDialog из QWebView (многие делали отчёты на html), это очень не понравилось многим разработчикам.
вот пример сломанной разметки
This comment wasn’t rated yet0
UFO just landed and posted this here

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


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

Total votes 9: ↑9 and ↓0+9
Нет. Поэтому QtC такое и вытворяет.
Total votes 4: ↑4 and ↓0+4
UFO just landed and posted this here
Ну почему, в некотором смысле аналоги есть. Те же GTK или wxWidgets. Но полноценного конкурента для Qt во всех его нишах (cross-platform desktop, embedded, mobile), думаю, нет. В его развитие очень сильно и долго вкладывались, и сделали реально мощную вещь, с которой непросто конкурировать. Поэтому и лицензирование такое — могут себе позволить, так сказать.
Total votes 6: ↑6 and ↓0+6
Qt — это не UI.
Qt — это огромный фреймфорв и UI в нём — это лишь одна из областей для которых он пригоден.
Total votes 5: ↑5 and ↓0+5
Widgets, QML и сопутствующее им половину всех dll и занимают.
А всему остальному замену найти как раз несложно.
This comment wasn’t rated yet0
UFO just landed and posted this here
Вроде бы Word не использует mfc и другие библиотеки, которые microsoft даёт сторонним разработчикам, при этом он есть и под mac — то есть относительно кроссплатформенен, не все компании открывают свои наработки, а делают их только для себя, чтобы иметь конкурентные преимущества
This comment wasn’t rated yet0

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

This comment wasn’t rated yet0
UFO just landed and posted this here
Господа минусующие, вы знак вопроса видите? Это вопрос был, а не утверждение. Если Джава не соответствует вопросу:
А какие вообще есть альтернативы QT, чтобы и интерфейс было относительно просто реализовать (приличный редактор форм, вполне вменяемая реализация взаимодействия между элементами интерфейса и остальным кодом), и реализации всякого полезного были (работа со списками, деревьями, потоками и т.п.), и чтобы все было единообразно, логично, вменяемо и кроссплатформенно?

Может объясните — почему, если уж настолько не согласны, что ставите минус?
Total votes 7: ↑5 and ↓2+3
Вроде OpenJFX живет, так что да
This comment wasn’t rated yet0
Мы тут для embedded-проекта сравнивали Qt и JFX,… если кратко, это только на бумаге они конкуренты. Qt заводится с полпинка, среда ставится элементарно, документация нормальная, на арме не тормозит, поддержку аппаратного ускорения отрисовки имеет… Ничего из этого нет в jFX. В дополнение к этому, экосистема и комьюнити вокруг jfx практически нулевая, по сранению с Qt, а уж в области embedded тем более.
Total votes 3: ↑3 and ↓0+3
Embedded в условии не было. Было бы глупо ожидать производительности нативного c++ фреймворка от виртуальной машины Джавы. Они конкуренты разве-что на десктопе.
This comment wasn’t rated yet0
по сравнению с Кьюти это просто боль и страдание. Зато контролы нативные, но больше плюсов нет, все остальное минусы.
Total votes 2: ↑2 and ↓0+2
Я тоже так всегда думал, пока не увидел вот это видео, оказалось там не всё так плохо.
www.youtube.com/watch?v=FOIbK4bJKS8
www.youtube.com/watch?v=FwUGeV2fnfM

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

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

Шарп уже умеет компилиться в нейтив, кстати.
Total votes 2: ↑2 and ↓0+2
Встроенный Делфи копмпилятор всё таки пошустрее FPC. Но тут есть нюанс: FPC умеет собирать бинари с помощью LLVM тоже на некоторых платформах и вот можно было бы попробовать разные варианты. В FPC пошли дальше Делфи — в качестве бэка сборки можно юзать и свой компилятор и LLVM и JVM и сборку в JS (вот как раз пишут). Думаю, что и на другие платформы будет LLVM бэк дописан, FPC очень активно развивается в последнее время.
wiki.freepascal.org/LLVM
Total votes 2: ↑1 and ↓10
Раз в пару лет пробую поставить Lazarus, собрать проект по умолчанию (с одним пустым окном) и всегда компиляция падает на каких-то странных ошибках(
Total votes 1: ↑1 and ↓0+1

Странно… А можно подробнее?

This comment wasn’t rated yet0
Что пишет то хоть? :) У нас вот проекты под миллион строк работают без каких-то особенностей и на винде и на линухе.
Total votes 2: ↑1 and ↓10
Хех, сейчас поставил на чистую убутнту 18.04, и… все работает, ура! Кажется, раньше я пробовал это всё на винде, хотя не помню, несколько лет уже не проверял.
This comment wasn’t rated yet0
На винде наверное удобнее, но в убунте все-таки apt install lazarus удобнее
This comment wasn’t rated yet0
Зависит от того, какая версия в репе лежит. Мы ставили Лазарь уже на примерно семи разных сбороках Линухов, fpcupdeluxe удобнее.
This comment wasn’t rated yet0
  1. Проблем несколько.
    Во-первых, глючные до безобразия IDE после версии 5.5.
    Во-вторых, перенос проектов на новую версию IDE может превращаться в серьезную проблему в случае использования сторонних визуальных компонентов. А порой и без использования оных можно получить проблем в полной мере (один переход на Unicode чего стоил, долгожданный, но, как именно его сделали...).
  2. Во-первых, среда разработки только под Windows. Для меня это уже серьезный минус.
    Во-вторых разработка под некоторые платформы не просматривается, в то время как Qt там основной вариант (тот же Sailfish).
  3. Lazarus, конечно, вещь интересная, даже пользую его иногда, но это совсем не Delphi. Это даже до версии 5.5 по удобству не дотягивает. Особенно "радует" необходимость пересборки всей IDE при добавлении визуальных компонент.
Total votes 1: ↑1 and ↓0+1
1) Юникод уже более десяти лет назад был, все компоненты перенесены и очень давно. Я сам три проекта примерно около млн строк перенес на уникод полностью за примерно неделю вместе с компонентами, вот примерно в 2010м году, да. По стабильности — сижу на XE6, работает неделями без единого сбоя. Да, проблемные версии были, они известны. Не обязательно их использовать.
2) Если не нравится Delphi которая действительно только под Win, то Лазарус в помощь, он работает 'по месту', сам постоянно в Линуксе на нем сижу.
3) Пересборка идет довольно шустро, примерно 15 секунд вся среда с компонентам пересобирается и их можно ставить 'пачкой', особых сложностей это не доставляет
This comment wasn’t rated yet0
К слову — пилят подобие bpl в Лазаре. Так что текущее состояние не на всегда. Смогут копмоненты устанавливаться точно так же как в Delphi.
This comment wasn’t rated yet0

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


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

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

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

This comment wasn’t rated yet0

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

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

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

Total votes 17: ↑11 and ↓6+5
Кто б сомневался, что и тут будут Rust рекомендовать :) Вроде как автора вполне себе С++ устраивает. Но это безусловно намного лучше, чем выбор PHP :)
Total votes 22: ↑12 and ↓10+2
UFO just landed and posted this here
Флаттер ни под десктоп, ни под веб пока ещё не очень то юзабелен. Даже начальных релизов ещё не было, мастер только тащить. Только под Мак альфа вышла, насколько помню.
Последний раз, когда пробовал его, даже примеры из SDK были поломаны и не собирались. Так что, до Кьюта ему ещё долго ползти.
This comment wasn’t rated yet0

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

Total votes 3: ↑2 and ↓1+1

единственное, что спасет — полностью открытый проект ?

This comment wasn’t rated yet0

Как очередной виток.

This comment wasn’t rated yet0
А кто его разрабатывать то будет?
This comment wasn’t rated yet0
Прочитать столько интригующего текста, что бы напороться на PHP…
Total votes 35: ↑28 and ↓7+21

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

This comment wasn’t rated yet0

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

Total votes 6: ↑4 and ↓2+2
Вы уж извините, но в госструктуру я пойду в последнюю очередь=) Я лучше выучу rust или go (да даже php вспомню!) чем буду писать на уютной кутешечке на государство=)
Total votes 24: ↑22 and ↓2+20

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

Total votes 6: ↑6 and ↓0+6
Судя по заказам на Upwork, большинство проектов десктопных приложений заказчики ожидают видеть на C#, WinForms. Qt очень редко нужен под Windows, чуть чаще под Mac и практически никогда под Linux.
Кроссплатформенность Qt конечно отличная штука, но далеко не всегда она нужна.
Вот и получается, что если начнут закручивать гайки в Qt, можно перебраться на C#.
Total votes 7: ↑4 and ↓3+1
Qt очень редко нужен под Windows, чуть чаще под Mac и практически никогда под Linux.

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

Total votes 13: ↑13 and ↓0+13
Именно WinForms? Не WPF разве (если речь о новом проекте, не легаси)?
Total votes 1: ↑1 and ↓0+1
Вот и получается, что если начнут закручивать гайки в Qt, можно перебраться на C#.

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

А еще есть JavaFX, кросс-платформенно, удобно и не php.

Total votes 10: ↑3 and ↓7-4

Который жутко тормозит в сравнении с 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 много лучше будет конечно.

Total votes 7: ↑3 and ↓4-1
Не надо такие видео в адекватных сообществах показывать. Вы хотя бы на дизлайки в видео посмотрите и комментарии прочитайте. Не говоря уже о том, что сравнивать производительность без кода это как верить в статиистику без источников данных.
Total votes 9: ↑7 and ↓2+5

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


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

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

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

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

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

Total votes 2: ↑1 and ↓10

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

This comment wasn’t rated yet0

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

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

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

Total votes 1: ↑1 and ↓0+1
А, вы в плане вставки кастомных компонентов. Это да. Сам сейчас копаю сей вопрос. Теоретически можно (всякие Flash в своё время так и встраивались со стороны браузера), но явно не просто
This comment wasn’t rated yet0
можно было

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

This comment wasn’t rated yet0

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

This comment wasn’t rated yet0

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

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

Есть надежда что WebAssembly позволит точно так же, но в html
This comment wasn’t rated yet0

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

This comment wasn’t rated yet0
Уже это немало, особенно если разовьют идею.
This comment wasn’t rated yet0
И для некоторых вроде меня явная нелюбовь разработчиков Qt к QВиджетам вызывает неприятные ощущения под спинным мозгом.
Total votes 2: ↑2 and ↓0+2
Может дело в прямоте рук? Вон intellij idea на swing работает шустро, а это более старая технология.
Total votes 1: ↑0 and ↓1-1
совсем не шустро, а в виртуалке так даже напряжно
This comment wasn’t rated yet0

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

This comment wasn’t rated yet0

Если сравнивать с KDevelop, то IntelliJ — тот ещё тормоз.

Total votes 1: ↑1 and ↓0+1

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

Total votes 1: ↑1 and ↓0+1
UFO just landed and posted this here
Там им в комментах написали, что даже для rpi3 интерфейс сильно тормозит.
This comment wasn’t rated yet0
Немного не профессионально. Мало того, что там видео заминусили, так вы сюда тащите этот шлак как аргумент.
Вы бы еще видео Антона Полухина здесь запостили.
Давайте с примерами, того, что можно запустить у себя на машине. Я начну.

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

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

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

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

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

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

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

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

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

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

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

Total votes 1: ↑0 and ↓1-1

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

Total votes 1: ↑0 and ↓1-1
У Java максимальный throughput при заданном железе, но если надо гарантировать 95% заданной скорости, например 10 мс на http response, то это не работает.
Потому что, 1) JIT — который пока раскочегарится и соберет статистику 2) GC — может выпадать в ненужные моменты.
По сути если мерить кол-во http response в 1 минуту на заданное железе, то throughput будет одинаковый или лучше. А вот хвост 5-15% самых медленных запросов, будет гораздо хуже.
This comment wasn’t rated yet0
в видео демки запущены на дохлых планшетиках. что вполне соответствует панелькам в промышленности или автомобильных
This comment wasn’t rated yet0
UFO just landed and posted this here
Проблема в том, что Qt можно легко интегрировать с другими библиотеками на C++, а у флаттера будут проблемы.
This comment wasn’t rated yet0
UFO just landed and posted this here
В целом flutter очень близок к qml
Идеологически может и да, а по синтаксису сильно хуже :/
Total votes 1: ↑1 and ↓0+1
UFO just landed and posted this here
Что еще ждать от Qt?! Они уже пару десятилетий не могут пофиксить корректную работу путей в windows, содержащих нелатинские символы.
Total votes 3: ↑3 and ↓0+3

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

Total votes 3: ↑3 and ↓0+3
UFO just landed and posted this here
UFO just landed and posted this here

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

Total votes 1: ↑1 and ↓0+1
У wxWidgets вроде все совсем плохо с мобильными платформами.
Total votes 3: ↑3 and ↓0+3
Зачем нужен JNI, когда есть JNA
This comment wasn’t rated yet0
Пытался написать на wxWidgets десктоп приложение лет десять назад. Количество плохо документированных функций, непонятных багов ( когда нужно делать именно так а не иначе чтоб работа ) просто поражаеет. Не знаю улучшились ли они за эти годы, но тогда это был плохой выбор.
Total votes 1: ↑1 and ↓0+1

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

This comment wasn’t rated yet0
UFO just landed and posted this here

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

Total votes 5: ↑5 and ↓0+5
UFO just landed and posted this here
Захотят закрыть фреймворк — закроют
Полностью — не могут. У них контракт с KDE, по которому они обязаны открывать код не позднее чем через год после его появления под коммерческой лицензией.
Total votes 1: ↑1 and ↓0+1
UFO just landed and posted this here
UFO just landed and posted this here
У меня недавно получилось написать вот такой код кнопки для приложения из соседней статьи. Это универсальная (внутри приложения) расширяемая кнопка списка с иконкой, заголовком и подзаголовком. Код слегка многословный, потому что предпочитаю полный контроль над отображением.
В простейшем же случае это будет

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


This comment wasn’t rated yet0
UFO just landed and posted this here
Да, это я зря, у Button'a и так все есть :) Не проснулся!
This comment wasn’t rated yet0
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Те, кто говорят про 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 уже давно такая политика. Они постоянно балансируют между стремлением заработать денег и стремлением не потерять сообщество. И будут этим заниматься дальше. Такова их тяжелая доля. Устраивать по этому поводу истерики я бы не стал.
Total votes 2: ↑2 and ↓0+2
UFO just landed and posted this here
Стандартная кнопка из Quick Controls 2 с иконкой и текстом под ней будет выглядеть примерно так:

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


Искаропки, естественно. Плюс ее можно дополнительно стилизовать. Ну а так да, способов просто миллион.
Total votes 2: ↑2 and ↓0+2
Закрытие фреймворка в эти дни эквивалентно форку, поэтому этот сценарий хоть и является неприятным, но не пугает.
там слишком много экспертизы нужно, чтобы поддерживать и qml, и widgets, и moc, и кросс-платформенность, и qt core
Мне кажется Вы недооцениваете сообщество. Люди коммитят в .NET Core, в Go, в VS Code, в K8S — там тоже многослойно.
This comment wasn’t rated yet0
Спасибо за наводку, но я тоже в своё время его пробовал, тоже понравилось. Пока не применил на Андроиде. Не знаю как сейчас, но тогда интерфейс прям вот очень заметно тормозил. Не то что медленно, а именно тормозил. Но я даже не про скорость, а про то, что такие вещи намекают на «зрелость» продукта. А так да — Kivy приятная штука.
This comment wasn’t rated yet0
В kivy всё прекрасно, но их сайт не открывается (спасибо РКН). И когда надо распространить результаты своего творчества, вы будите виселиться (виселица находится в конце деревни).
This comment wasn’t rated yet0
UFO just landed and posted this here

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

Total votes 7: ↑7 and ↓0+7
Они в том числе перекрывают возможность создания проектов по MIT лицензии, если программист будет использовать какие-то GPL библиотеки от Qt. А как видно, Qt всё больше своих библиотек распространяет по GPL лицензии в бесплатной версии. При LGPL такая возможность была.
This comment wasn’t rated yet0

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


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

Total votes 2: ↑2 and ↓0+2
Ну, лично я тогда относился к ней с осторожностью, потому что использовать по работе один фреймворк, а для себя — другой неудобно.
This comment wasn’t rated yet0
Вопрос не дурацкий. Нет, не только этим. Меня волнуют последствия и как это скажется на продукте. Если сейчас годами баги висят, то что там при политических пертурбациях дальше может получиться…
This comment wasn’t rated yet0
Если сейчас годами баги висят, то что там при политических пертурбациях дальше может получиться…

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


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


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


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

Total votes 1: ↑1 and ↓0+1

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

This comment wasn’t rated yet0

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


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


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

This comment wasn’t rated yet0

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

This comment wasn’t rated yet0

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

This comment wasn’t rated yet0
Меня сейчас, наверно, заминусуют, но поймите меня правильно: я люблю Qt, но если есть на выбор вариант «просто использовать» или «использовать с обязательным условием вклада (денег, времени и т.п.)», я выберу первое.
И источник денег выберет первое.
Да, я могу править баги, писать свою виртуальную клавиатуру под Андроид, графики самостоятельно рисовать, чтобы «быть добропорядочным использователем библиотеки».
Но зачем мне это, если я просто могу использовать charts.js, отдать ему json из любого места, и пойти дальше?
Тут кто-то спрашивал про датагриды «не-Qt». Я вот специально в заметке указал, что я не буду в детали вдаваться, а то бодания начнутся до бесконечности. Потому что кому-то Ext JS надо, а кому-то onclick() на кнопку достаточно. И они друг друга понимать не будут. (Вон уже «Electron с PHP на борту» кто-то озвучил...)
Но именно там кроется одно из преимуществ веба: там всего — дофига и больше.
Total votes 1: ↑1 and ↓0+1

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

Total votes 1: ↑1 and ↓0+1
Но именно там кроется одно из преимуществ веба: там всего — дофига и больше.

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

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

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

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

Для меня показателен пример с 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 и не будет даже об этом думать.

Total votes 1: ↑1 and ↓0+1
Подскажите где он в Qt Marketplace, я что то не нашел, в составе какого то пакета?
This comment wasn’t rated yet0

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

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

В итоге я помучался, помучался, пособирал дистрибутив под мак ось бессонными ночами (ага, кросс-платформенность, но приложения еще и доставлять как-то надо) и в итоге написал все на вебе. Приложение у меня нетребовательное к ресурсам.
Total votes 1: ↑1 and ↓0+1
Интересно, какого размера будет Hello World при использовании связки C++ и PHP? И сколько мегабайт оперативки будет съедать простое приложение состоящее из одного окна и нескольких кнопок?
This comment wasn’t rated yet0
Допустим у меня есть CAD приложение, в котором GUI сделан на Qt. Как в нём можно заменить GUI на HTML/CSS/JS/PHP? Как это будет выглядеть? Каждая панель с кнопками это WEB-страница? Для каждого Message Box строится DOM, запускается интерпретатор и виртуальная машина?
Total votes 1: ↑0 and ↓1-1
Допустим у меня есть CAD приложение, в котором GUI сделан на Qt. Как в нём можно заменить GUI на HTML/CSS/JS/PHP?

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

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

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

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

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

Total votes 1: ↑1 and ↓0+1
wasm это не нативный код, а браузер сожрет свои 100Мб/страницу

пока что выглядит хуже альтернатив
Total votes 4: ↑2 and ↓20
Почему wasm — не нативный код? Вполне себе. Сколько там сожрёт браузер, мне совершенно не интересно. Если всё это закончиться тем, что код на плюсах что-то посчитает и сможет это показать в HTML без JS со всякими там его динамическими типизациями и GC, то меня это полностью устроит и по производительности, и по внешнему виду.
This comment wasn’t rated yet0
потому что wasm это байт код очередной виртуальной машины.

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

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

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

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

В мире, где уязвимо все, железо, софт, вы предлагаете рассылать пользакам голый бинарь?
Запускать бинарь в песочнице дешевле, чем крутить интерпретатор виртуального кода.
Total votes 2: ↑2 and ↓0+2
Вы только что жаловались на отсутствие аргументации и тут же сами эту аргументацию опустили.

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

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

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

Ой, а память вы завезли грузовиком?
Total votes 3: ↑3 and ↓0+3

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


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


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

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

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

Понимаешь, что мир немного пошел не туда. И ничего с этим поделать нельзя.
Но ничего страшного, покуда человек разумен, рано или поздно мы начнем думать про перформанс.
Так же как и про корону, когда упремся в потолок.
Это заложено в нас генетически. Идем по пути меньшего сопротивления.
Не так эффективно как могли бы )))
Total votes 1: ↑1 and ↓0+1

А как прекрасно работают жесты на N900

This comment wasn’t rated yet0
Ну, на N950 их уже сделали. Правда, Qt Widgets убили, но это уже Microsoft. А на N900 зато был стилус. Каждый раз, когда приходится что-то делать на морозе (у нас тут, чай, не Калифорния), его вспоминаю. Впрочем, кроме зума из жестов я ничего не использую, может, поэтому так.
This comment wasn’t rated yet0

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

Total votes 1: ↑1 and ↓0+1
Да, это удивительно, ибо только сейчас более-менее жесты пришли в андроид.
Хотя жизнеспособность концепции была проверена лет 10 назад.
This comment wasn’t rated yet0
Но используются они в Android совсем не так широко.
This comment wasn’t rated yet0

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

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

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

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

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

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

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

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

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

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

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

И напомню исходный мой посыл, чтобы не отдаляться от темы.
Total votes 1: ↑1 and ↓0+1
Я теряю логику ваших высказываний.
Проблема с памятью в браузерах таки есть.

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

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

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

Total votes 1: ↑0 and ↓1-1
UFO just landed and posted this here
Если вы не поняли, речь идет про эмбедед vs носимые у нас в карманах «суперкомпьютеры».
И телефон с 4ГБ рам за 8тр, сейчас норма. Так что не вижу с чем вы тут спорите.
Учитывая, что эти цифры растут уверенными темпами.

Ну и васм, по сравнению с современным вэбом памяти потребляет столько, что этим можно пренебречь.
Total votes 2: ↑0 and ↓2-2
Эм, webasm на данный момент медленне JS, просто потому что для работы с браузером он юзает виртуальную машину и генериться байт код JS, если мне память не изменяет. И если продолжать то V8 написан на C++, вопрос «Зачем тогда нам не только JS и PHP, а ещё HTML и CSS?». Если мы говорим о будущем, то почему мы не можем расширить QML до уровня HTML + CSS? И в целом почему на не заменить весь веб на связки Rust + Python, или Python + имеющийся xml формат?
P.s. в идеале тогда и форматы текстовых документов привести к единому xml формату.
This comment wasn’t rated yet0

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

This comment wasn’t rated yet0
UFO just landed and posted this here
Не уверен, что правильно понял вопрос, но если это вообще про «как начать», то можно даже без фреймворков для простых панелей обойтись.
Просто: 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, фреймворков много.
This comment wasn’t rated yet0
А есть аналоги для embedded (embedded уровня одноплатников типа rpi)? Пробовали сравнить с OpenJFX — последняя дико тормозит, т.к. при использовании без иксов вся отрисовка там софтовая, а qt летает, потому что использует OpenGl (На самом деле не все так очевидно, потому что тестировали в том числе и на beaglebone black, у которого OpenGl, вполне возможно, не был доступен ни тому приложению, ни другому).
This comment wasn’t rated yet0

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

This comment wasn’t rated yet0
Да, вероятно, в демках Qt была часть с каким-то легким 3Д, и она летала. А в JFX даже курсор мыши заметно отставал от самой мыши.
This comment wasn’t rated yet0
Лет 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 как минимум сложно и ресурсоёмко.
Total votes 1: ↑1 and ↓0+1
Для KDE и прочего не автомобильно/иотного/мобильного последнего актуального LTS ещё на десяток лет вперёд хватит. Достаточно будет бэкпортить фиксы на явные баги
This comment wasn’t rated yet0

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

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

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

This comment wasn’t rated yet0

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

This comment wasn’t rated yet0
А как быть, если все таки хочется использовать open source версию Qt для своих закрытых android приложений(в том числе коммерческих)? Как мне предоставить возможность пересборки с другими версиями Qt? Достаточно ли будет фразы в духе «если хотите пересобрать приложение с другой версий Qt, то напишите мне на почту» и по запросу высылать портянку инструкций вместе с make, obj и другими файлами?
This comment wasn’t rated yet0
В моём скромном понимании, по электронной почте по запросу нельзя (если только продукт не распространяется по электронной почте или с письменной офертой). Продукт, лицензия, инструкции и исходники должны быть из одного публично доступного источника, либо должно быть чётко написано где скачать вышеуказанное. И это место должно быть доступно пользователю пока действует лицензия.
Total votes 1: ↑1 and ↓0+1
Как раз по запросу и надо. Так вас обязывают предоставлять это не всем подряд, а только официальным пользователям (если у вас коммерческое ПО).
This comment wasn’t rated yet0
Опять-таки, в моём скромном понимании (а оно такое у всех, потому что GPL специально так написана):
В п.4e LGPL указано на предоставление интрукций методом п.6 GPL.
При распространении через Play Store, смотрим в GPL на п.6d. Так что всё-таки без дополнительных запросов надо обеспечивать.
Если не через Play Store, я сделал оговорку в скобках выше.
Total votes 2: ↑2 and ↓0+2
На сервере может быть пароль на вход, или личный кабинет чтобы убедиться что пользователь получил ПО именно от вас. Ведь если он получил его не напрямую от вас, то и GPL обязательства к нему у этого третьего лица а не у вас. А если вообще не получал а сразу хочет исходников — то GPL вас вообще не связывает и не обязывает.
This comment wasn’t rated yet0
На сервере может быть пароль на вход, или личный кабинет чтобы убедиться что пользователь получил ПО именно от вас
Да, если распространялось ПО таким же образом.
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
This comment wasn’t rated yet0
В сторе андроида без ввода пароля тоже ничего не купить, так что эквивалентно.
This comment wasn’t rated yet0
Просто Elsedar про «напишите мне на почту» говорил. А это вряд ли эквивалентно.
Total votes 1: ↑1 and ↓0+1
А если ПО распространяется сразу на железяке, какие там equivalent copying facilities?
Total votes 1: ↑1 and ↓0+1

Тогда это не пункт 6d. А в 6a и 6b про это не говорится.

This comment wasn’t rated yet0
Я честно пытался разобраться в этих лицензиях, но я и на русском едва ли могу такие тексты читать, а на английском еще быстрее теряюсь.

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

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

Т.е. если в инструкции указано как поменять LGPL-компоненты внутри (чего бы то ни было, что вы распространяете), то этого достаточно при динамическом связывании.
Total votes 1: ↑1 and ↓0+1
Спасибо!

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

Тогда получается, что все не так уж и плохо с магазинами приложений?
This comment wasn’t rated yet0
Тогда получается, что все не так уж и плохо с магазинами приложений?

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

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


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

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


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


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


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


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

This comment wasn’t rated yet0

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


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

This comment wasn’t rated yet0
Рост спроса на веб и мобилы, и, по факту, отсутствие решений для этого со стороны Qt

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

This comment wasn’t rated yet0
Я работаю в основном с PHP и эта статья для меня как бальзам) Спасибо
This comment wasn’t rated yet0
Для Делфистов статья тоже до какой-то степени бальзам :) Мы то всегда знали, что бесплатный сыр — он только в мышеловке. Очередное подтверждение.
This comment wasn’t rated yet0
Как в том анекдоте — «Лозунг-то гарный… цiль погана». Заменить десктопное гуй приложение вебовским с неизвестно откуда взявшимся сервером на пыхе… ну так себе альтернатива. Особенно если приложение — системная утилита, например.
This comment wasn’t rated yet0
Есть такая штука — java. Производительность как у си, нативная переносимость без перекомпиляции и совершенно офигительный UI framework. Не говоря уж о сотне других фреймворков на все случаи жизни.
Total votes 5: ↑1 and ↓4-3

Если только как шутка

Total votes 1: ↑1 and ↓0+1
Вот что я хочу сказать по поводу этого…
1. PHP в этой схеме не нужен. UI часть целиком можно реализовать на Javascript (или Typescript) в форме Single Page Application на любом JS фреймворке. Далее найти какую-нибудь приличную C++ библиотеку для реализации протокола HTTP и выдачи статических файлов (с кодом, реализующим UI логику). Полезные данные передавать прямо из/в C++ путём (де)сериализации в формат JSON (также можно передавать данные как изображения PNG/JPEG/GIF и даже в бинарном виде)
2. PHP в этой схеме вреден. Потому что:
а) Часть UI логики окажется написана на Javascript, часть на PHP. Потом непременно возникнут пересечения по функционалу в той и другой части, но повторно использовать один и тот же код будет невозможно, потому что языки разные. В общем чем меньше языков — тем лучше, особенно если два разных языка отвечают за сходные задачи.
б) Интерпретатор PHP сожрёт лишнюю память и утяжелит установочный пакет.
3. Ваше приложение будет либо открываться в окне браузера, либо вам придётся встраивать в свой установочный пакет собственный браузер «без рамки». Это много мегабайт (предположительно заметно больше чем Qt, но я не измерял, если что:) И памяти оно тоже сожрёт. Для большого приложения вряд ли это будет критично, а вот для маленькой софтинки из пары окон и десятка кнопок — неприятно.
This comment wasn’t rated yet0

Articles

Show the best of all time

Your account

Sections

Information

Services

Support
© 2006–2024, Habr