Комментарии 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, так что программисты будут его учить, т.к. он перспективный и т.д. и т.п.
А не сможет — ну, откатит лицензионную модель обратно.
Оу… Electron с PHP на борту?
Завораживает.
Всякие std::optional/std::variant завезут только в 6ке и тоже непонятно когда и куда (у TQtC явно не хватает рук да и те разбегаются).
К сожалению, Qt всё дальше отстает от апстрима С++.
Ну как раз апстрим взял то, что в Qt было очень давно: variant, future, thread, smart-pointers и многое другое.
На дворе 2к20й а людям всё ещё надо доказывать что smart-pointer'ы это хорошо и правильно (и нет, в Qt6 их не будет, будем как в 90х делать parent-child на raw-поинтерах).
QPointer, QAtomicPointer, QSharedPointer and QWeakPointer — не то?! См. вики: https://wiki.qt.io/Smart_Pointers. Появились гораздо раньше, чем аналоги в C++!
class ThreadWrapper {
virtual void run() = 0; // Этот метод будет запущен в потоке
void start() { // Запуск потока }
~ThreadWrapper() {
// Остановка потока
}
}
Вот только проблема в том, что когда выполнение программы дойдет до деструктора ThreadWrapper, производный класс уже будет уничтожен, и стопать в этот момент тред уже бесмысленно (скорее всего он там уже что-то напортил, так как работал с методом уничтоженного класса).
Как эту проблему решить не через parent-child?
Решается через некий ThreadManager, который сам позовет виртуальный метод stop у всех потоков. Менеджер можно даже синглтоном сделать, в котором каждый ThreadWrapper регистрируется при создании. Если других задач менеджеру не давать, то вполне рабочий вариант. Но и руками не забывать перед удалением stop говорить (собсна тот же std::thread развалится, если позвать деструктор, когда тред ещё работает, здесь даже попроще выйдет интерфейс, ну или совсем если мудрить, то в пользование отдавать всем простейший враппер над вашим тредвраппером, который в деструкторе будет звать у тред стоп и его деструктор)
Qt 5 вышел в 2012 году, когда этих всех плюшек ещё не было, а начали его делать ещё раньше. По ходу дела так серьёзно менять API они не могли. В 6-ке уже можно будет: https://habr.com/ru/post/501798/?reply_to=21613662#comment_21613378
Ну как раз апстрим взял то, что в Qt было очень давно: variant, future, thread, smart-pointers и многое другое.
std::variant имеет очень отдаленное отношение к QVariant (и вообще, QVariant это скорее std::any). И пришел он в стандарт из буста а не из Qt.
Аналогично, thread — тоже из буста.
Насчет указателей не уверен, но они появились задолго до стандарта в tr1 и скорее всего пришли в Qt оттуда (просто комитет тогда был слоупоком и не принимал их).
QPointer, QAtomicPointer, QSharedPointer and QWeakPointer — не то?!
Они там ест но даже новый код пишется без их использования, например, QThread::create который возвращает голый указатель на созданный тред. Каждый раз когда я использую этот метод, я его заворачиваю в unique_ptr.
Или например тредпул который берет раннаблы с булкой «надо ли удалять раннабл» (autoDelete), что приводит к рейсу, который описан в документации (кек). А всего-то надо передавать шаред_птр на раннабл — и булка не нужна и рейс уходит.
Из всех smart pointer в самой Qt активно используется только QPointer. Что мешает пойти дальше и начать использовать остальные указатели — яхз.
Или например тредпул который берет раннаблы с булкой «надо ли удалять раннабл» (autoDelete), что приводит к рейсу, который описан в документации (кек). А всего-то надо передавать шаред_птр на раннабл — и булка не нужна и рейс уходит.
А можно по-русски пожалуйста и с примером в целях повышения образованности? :)
setAutoDelete(false) нужен для того, чтобы переиспользовать раннаблы несколько раз. Например, мы хотим запускать раннабл дважды:
auto tp = QThreadPool::globalInstance();
auto run = new Runnable(); // класс наследует QRunnable и что-то исполняет
run->setAutoDelete(false); // хотим переиспользовать
tp->start(run); // запустили первый раз
tp->start(run); // запустили второй раз
run->setAutoDelete(true);
/* а вот так^ делать нельзя, потому что пул мог уже
обработать раннаблы и не успеть прочитать булку. Это поведение
описано в документации, "пожалуйста, не стреляйте себе в ногу"*/
Теперь тот же юзкейз на shared_ptr:
auto tp = QThreadPool::globalInstance();
auto run = std::make_shared<Runnable>();
tp->start(run); // запустили первый раз
tp->start(run); // запустили второй раз
Фишка в том, что мы получили тот же юзкейз и нам эта булка вообще не нужна, нам нужен атомарный счетчик ссылок на раннабл. Если в пуле лежит 2 раннаблы, объект будет жив пока не исполнится последняя. Если мы держим ссылку вне пула, то тоже всё хорошо — пул ничего не удалит, а просто выкинет свои копии указателя.
Кода меньше, код безопаснее, нет corner-case'ов которые надо описывать в документации. Одни плюсы.
и нет, в Qt6 их не будетв смысле?
Всякие QScopedArrayPointer и QSharedPointer — есть уже чёрти сколько лет.
Да, иерархия QObject использует сырые указатели — но там дерево объектов само отслеживает время их жизни, т.е. по сути является smart pointer'ом; добавлять туда ещё — это во многом бесполезное дублирование функциональности.
Обычно авторам таких высказываний неважно — как только обнаружен код без smart pointer'ов, делается вывод про качество всей библиотеки. И не интересует ни её объем, ни исторический (и надо сказать прекрасно себя показавший) подход к разработке — когда используется гарантированно поддерживаемый всеми компиляторами минимальный остов языка, ни устоявшиеся API с сырыми указателями… Надо smart и все тут, даже если это последий пункт в очереди болящих вещей.
И аргументов типа «сломается много кода» там нетДо этого даже не дошло мб?
А все же — какую проблему планировали решить данным proposal'ом?
Абсолютно неочевидная передача владение в куче случаев. QMainWindow::setCentralWidget репарентит виджет. QAbstractItemModel::setModel не репарентит модель несмотря на абсолютно аналогичное название.
QLayout::addWidget репарентит виджет.
QMenu::addAction не репарентит экшн.
Глядя на сигнатуру\вызов метода невозможно понять, передается владение или нет, что ведет к постоянным багам (не все смотрят в документацию каждый раз).
Хорошо если метод называется takeItem, можно угадать что он отдает овнершип юзеру… Но если юзер не догададется, получим утечку.
До этого даже не дошло мб?
Почитайте рассылку, там реально аргументы уровня студента (причем не от самих кутешников, а от каких-то рандомов)
QMenu::addAction не репарентит экшн.И это правильно — один и тот же QAction может легко быть использован во множестве мест, в том числе и для ShortCut'ов, работающих везде в программе.
QAbstractItemModel::setModelНет такой.
Если вы про QAbstractItemView::setModel, то там тоже прямо сказано — одна модель may be shared between several views.
Глядя на сигнатуру\вызов метода невозможно понять, передается владение или нетВот это стоит исправить — сделать разные языковые конструкции для случаев когда владение забирается и когда просто даётся для использования.
Никто не говорит что это неправильно — это неочевидно при чтении кода. Код должен быть самодокументируемым и читающего не надо заставлять лезть в документацию, чтобы ответить на вопрос «нет ли тут утечки».
Примеры с addAction тривиальны, но есть места где приходится реально углубляться в чтение.
На самом деле, QLayout::addWidget гораздо лучше смотреть как пример. Я вот написал что он виджет репарентит, а на самом деле, он репарентит его не всегда, а только если лайаут чему-то назначен. Если у вас есть лайаут, ни к чему (ещё) не привязанный, вы сделали layout->addWidget(new Widget) и внезапно решили выйти из функциии (ну, например, настройки не считались)… Упс, утечка.
Да, это сомнительный corner-case, но его можно было бы избежать, использовав умные указатели.
не все смотрят в документацию каждый разВ этом и проблема. В документации Qt всегда прописано, что владеет объектом.
Мне понравилось, как написал 0xd34df00d в своей статье — в C++ постоянно нужно вдумчиво писать код, на каждой строчке предвидеть возможные последствия и UB. Ну починят «проблему» сырых указателей в Qt (с которой живет сам фреймворк и тонны софта на нем), так ведь все равно C++ предоставит кучу способов
И аргументов типа «сломается много кода» там нет, аргументы там были «да посмотрите вон на модуль ХХХ (вроде что-то с Xml) он написан на смартпоинтерах и там такооой говнокод».Если вы про вот это обсуждение — то там как раз всё в аргументах именно про «сломаются типичные паттерны использования» и «нам надо запилить свои смарт поинтеры для этого».
У Qt6 в планах C++17, минимальный поддерживаемый компилятор на винде MSVC 2019 (не уверен какой конкретно версии).
Внутри уже давно на стандартные смартпоинтеры переписывают.
Строки по умолчанию хотят utf-8 сделать и прочее, прочее
И они никуда не денутся, потому что на них завязана многопоточка причем на мой взгляд достаточно изящно.
Потом, никто не предлагает убирать иерархию, предлагают реализовать ее через unique/shared_ptr (и там уже есть счетчик слабых ссылок (а точнее вся дата QShared/QWeakPointer) в QObject для QPointer'а, например)
Как Вы собираетесь это реализовывать через unique/shared_ptr
Легко и изящно, parent-child отлично реализуется на unique_ptr (и можно даже сделать так что старый код будет работать).
0. QObject
1. TreemodelItem
2. Нода дерева
Вообще какую пользу даст эта замена?
Эта замена даст ту пользу что будет сложнее выстрелить себе в ногу (а сейчас сделать это ооочень легко) и передача владения будет явно выражена в коде:
window->setCentralWigdet(std::make_unique<QWidget>());Кстати, LGPL в Qt появилась не сразу — сначала там была только GPL.
Есть такая программка Yarxi. Разработчик её на Delphi написал. Собрал на краудфандинге 1500 евро на Delphi 10 Seattle. Его убеждали на Qt перескочить. Он устоял. Иначе бы вляпался в кабалу и пришлось бы словарик продавать по цене 2х Windows 10 major edition.
Не всё так адекватно для небольших компаний. Qt — это махровая коммерция для гигантов типа VAG и маленьким компаниям там делать нечего.
Иначе бы вляпался в кабалу и пришлось бы словарик продавать по цене 2х Windows 10 major edition.Чем вам не нравится бесплатная LGPL лицензия?
Василий Иванович, что такое нюанс?
Видишь ли Петька:
Иначе зачем тогда работают менеджеры и юристы в Qt Company?
Веб? Интерпретатор вместо нативной программы? Нет, пожалуйста, не надо, прошу! Нет!
вот пример сломанной разметки
А какие вообще есть альтернативы QT, чтобы и интерфейс было относительно просто реализовать (приличный редактор форм, вполне вменяемая реализация взаимодействия между элементами интерфейса и остальным кодом), и реализации всякого полезного были (работа со списками, деревьями, потоками и т.п.), и чтобы все было единообразно, логично, вменяемо и кроссплатформенно?
Я пока что-то ничего не нашел. Разве что Delphi/C++ Builder, но оно уже давно тоже куда-то не туда смотрит, да и с поддержкой разных платформ как-то не очень по сравнению с QT.
Qt — это огромный фреймфорв и UI в нём — это лишь одна из областей для которых он пригоден.
А какие вообще есть альтернативы QT, чтобы и интерфейс было относительно просто реализовать (приличный редактор форм, вполне вменяемая реализация взаимодействия между элементами интерфейса и остальным кодом), и реализации всякого полезного были (работа со списками, деревьями, потоками и т.п.), и чтобы все было единообразно, логично, вменяемо и кроссплатформенно?
Может объясните — почему, если уж настолько не согласны, что ставите минус?
wxWidgets.
www.youtube.com/watch?v=FOIbK4bJKS8
www.youtube.com/watch?v=FwUGeV2fnfM
Хотя я всё равно буду использовать Qt, мне она кажется логичнее и удобнее.
По сравнению с Qt — у других библиотек плохо с документацией.
Qt этим берёт, не просто перечисление методов, а примеры правильного использования!
Но её делал Жасмин Бланше и Саммерфилд, которые уже давно ушли, и как мне показалось в QML документация уже не такая качественная.
Я пока что-то ничего не нашел. Разве что Delphi/C++ Builder, но оно уже давно тоже куда-то не туда смотрит, да и с поддержкой разных платформ как-то не очень по сравнению с QT.1. Он как раз таки смотрит куда нужно в последние наверно лет 7+ :)
2. Каких платформ не хватает?
3. Существует полностью бесплатный FPC/Lazarus, который работает как говорят, хоть на утюгах :)
2. За счет нативного кода ниже шарпа скорость не может быть никак.
3. На мобильных платформах и Линуксе/OSX сборка в Delphi и Билдере идет с помощью LLVM, поэтому скорость сопоставима с другими срадами собирающими бинари LLVM'ом
Шарп уже умеет компилиться в нейтив, кстати.
wiki.freepascal.org/LLVM
Странно… А можно подробнее?
github.com/LongDirtyAnimAlf/fpcupdeluxe/releases
И на винде и на линуксах и на остальных платформах.
- Проблем несколько.
Во-первых, глючные до безобразия IDE после версии 5.5.
Во-вторых, перенос проектов на новую версию IDE может превращаться в серьезную проблему в случае использования сторонних визуальных компонентов. А порой и без использования оных можно получить проблем в полной мере (один переход на Unicode чего стоил, долгожданный, но, как именно его сделали...). - Во-первых, среда разработки только под Windows. Для меня это уже серьезный минус.
Во-вторых разработка под некоторые платформы не просматривается, в то время как Qt там основной вариант (тот же Sailfish). - Lazarus, конечно, вещь интересная, даже пользую его иногда, но это совсем не Delphi. Это даже до версии 5.5 по удобству не дотягивает. Особенно "радует" необходимость пересборки всей IDE при добавлении визуальных компонент.
2) Если не нравится Delphi которая действительно только под Win, то Лазарус в помощь, он работает 'по месту', сам постоянно в Линуксе на нем сижу.
3) Пересборка идет довольно шустро, примерно 15 секунд вся среда с компонентам пересобирается и их можно ставить 'пачкой', особых сложностей это не доставляет
1) Тем не менее в целом с обратной совместимостью проблемы были чаще, чем в Qt. Да и сторонних визуальных компонент, для которых не появлялись обновления под новые версии Delphi, очень много встречалось.
Еще вспомнился один занятный баг, который хорошо попил крови. При попытке сборке одного проекта под более новыми версиями Delphi, чем исходная 2005, на которой проект разрабатывался, постоянно получали странную ошибку. Что-то вроде "Internal error" с каким-то кодом. Причем никаких объяснений именно по данному типу ошибки нигде не было, по месту возникновения ошибки ничего понять не получалось.
Уже спустя несколько лет попыток таки собрать проект под новыми версиями Delphi случайно где-то в сети обнаружили упоминание, что в этом случае надо просто везде заменить object на class в объявлении классов. Что интересно, хватило изменения только в том модуле, при компиляции которого выдавалась ошибка.
3) У меня в 15 секунд не укладывается. обычно несколько минут. Впрочем, это не сильно меняет ситуацию. Пока по всем параметрам, определяющим удобство использования, до Qt ему далеко.
Хотя для "домашнего" пользования уже вполне годится.
Вы как-то все в прошлом застряли
Это просто самые яркие впечатления.
Впрочем, последние версии (после XE5) я действительно не пробовал, как-то совсем разочаровался к этому моменту. Может быть и зря, конечно.
Впрочем, желание попробовать последнюю версию производитель сам тут же убил в зародыше. Требовать телефон (без его указания просто не пустило дальше) за скачивание Community Edition — это как-то слишком.
А Qt пока за бесплатную версию не требует никаких персональных данных.
Кстати о lazarus, Qt для fpc оказывается есть. Интересное кино. Надо посмотреть-попробовать.
wiki.freepascal.org/Widgetset
В какой-то версии ядра (уже не помню точно)- немного сменили формат elf файлов и kylix перестал работать, а его приложения требовали патча.
Avalonia
А что насчет ну к примеру связки flutter + rust? Вроде как те же яйца, но на более новых технологиях.
Последний раз, когда пробовал его, даже примеры из SDK были поломаны и не собирались. Так что, до Кьюта ему ещё долго ползти.
Хм, ну запилят очередной Qt на php (или чем то другом), кончится все тем же — как только начнется массовое использование придут эффективные менеджеры и опять начнут требовать деньгу.
Забыл добавить, юзать ab для бенчмарков это моветон, он часто бывает сам тормознее тестируемого кода.
Немного слов в защиту. Хотелось обратить Ваше внимание, что все государственные структуры в настоящее время переводятся на AstraLinux, где это связка c++/qt доступна прямо из коробки. Это факт как раз может послужить к увеличению количества разработчиков именно на этой связке. Если я не ошибаюсь то разработка ПО для госструктур должна выполнялся на сертифицированных средствах.
Кроссплатформенность Qt конечно отличная штука, но далеко не всегда она нужна.
Вот и получается, что если начнут закручивать гайки в Qt, можно перебраться на C#.
Qt очень редко нужен под Windows, чуть чаще под Mac и практически никогда под Linux.
Очень спорное утверждение: как раз чаще всего на Линуксе — это и IoT, и embedded (что чаще всего) и Qt Automotive. Про Андроид вообще молчу: количество сильно растёт. Все проекты, на которых я работал на Qt (медицина, инжернерно-технические, управление временем и т.п.) были кросс-платформенные. Вообще отказ от Qt был бы катастрофой и замена его на Web или C# в большинстве проектов просто нереальна!!! Вот например в таких: https://github.com/mavlink/qgroundcontrol/ Это бред!
Вот и получается, что если начнут закручивать гайки в Qt, можно перебраться на C#.
Как человек который пробовал и то и другое, поверьте: с C# будет так плохо что лучше уж web-интерфейс. По производительности C# не тянет, при скрещивании C++ с C# возникает жирный промежуточный слой CLI, плюс логика реализации C# приложений радикально отличается от логики Qt приложений что в завязке на ситуацию когда вызовы могут ходить туда-сюда порождает совершенно нечитаемую логику приложения в целом (если в C++ есть какая-то логика а не набор отдельных вызываемых для скорости алгоритмов). Ну и WPF после QML — это очень больно и грустно.
А еще есть JavaFX, кросс-платформенно, удобно и не php.
Который жутко тормозит в сравнении с C++/Qt/QML.
Qt vs. JavaFX: https://www.youtube.com/watch?v=Kh6K-yEp_JY
HTML5 vs Qt: https://www.youtube.com/watch?v=Z4CwVN9RRbE
Посему для большинства приложений, где используется Qt, где нужна скорость или есть тяжёлые вычисления и нужна высокая скорость передачи данных ни Web ни Java ни вариант. Хотя Java много лучше будет конечно.
Что ты называешь "адеватным" сообществом? Ты хочешь сказать, что Java будет быстрее C++?! Даже комментаторы там признают, что C++ производительнее. Подтверждаю на собственном опыте: когда-то хотел сделать программу на Java но UI и расчёт ИНС тормозил на ней жутко — в 2-3 раза (хотя может надо было наплевать с прицелом на будущие перспективы и уровень зп ;) ) — сделал на C++/Qt.
С видео о HTML5 в комментариях и лайках вообще ни у кого вопросов не возникло. Чтобы спорить здесь надо быть полным неадекватом.
- Мы всё еще о UI или вы из тех, кто вычисления в одном потоке с интерфейсом делает?
- Цифры относительно «тяжелых» вычислений и «высокой» скорости, конечно де у вас под рукой?
- Про большинство приложений тоже интересно увидеть цифры
- Про видосы, как уже сказали ниже — без кода — это мусор.
- UI, вычисления у нас конечно в отдельном потоке.
- Конечно: см. пост выше: Java была в 2-3 медленее на моих задачах
- Большинство приложений, где используется Qt: https://en.wikipedia.org/wiki/Qt_(software)
- Статья выше — это мусор или ты хочешь сказать, что JVM или HTML5 будут работать быстрее нативного кода C++/Qt? О чём здесь речь вообще?! Какие тебе цифры надо?
Ну кстати в теории же html + js по такой же схеме работают как и qml + js. И там и там язык разметки плюс клей из js.
Просто qml намного лучше задизайнен. А вот javafx увы, не сможет тягаться никогда, у нее сам рендер тоже на джаве, он никогда не будет столь же быстр как нативный.
Ну кстати в теории же html + js по такой же схеме работают как и qml + js. И там и там язык разметки плюс клей из js.
"В теории", а на практике, когда скорости JS начинает не хватать — переносишь логику в C++ и всё начинает летать на порядок быстрее — проверял. Ну и "разметка" в QML — это нативные C++ объекты QML Items с аппаратным ускорением, так что они тоже сильно быстрее HTML.
Я думаю htmlные теги тоже в итоге мапятся на нативные обьекты, да и логику же тоже можно писать в плюсах и прокидывать в вебню. По крайней мере, так точно можно было в QtWebKit делать
В QML можно реализовать любой новый элемент на плюсах, унаследовав его от QQuicklItem, если он визуальный, или просто от QObject, если нет, и легко и просто интегрировать его в остальной QML код. А вот как реализовать подобным образом кастомный html тег — я что-то сходу даже и не знаю.
На html+css+js делаем типичный веб UI (не исключено и использование популярных в js фреймворков). Далее делаем интерфейс C++ -> js. В QtWebKit это выглядело как C++ класс на одной стороне и аналогичный js объект на другой. Ну так вот, через этот интерфейс все данные и таскаем.
"Кастомный html тег не нужен" напоминает мне анекдот про "потребности в колбасе на сегодня нет". А если мне нужен именно визуальный компонент? Что мне толку с этого js объекта, если я не могу его отобразить? Мне придётся корячиться и пытаться лепить что-то на js стороне из DOM объектов. А с QML я на C++ стороне его нарисую именно так, как мне надо, хоть через scenegraph, хоть через QPainter, да и все. Быстро, просто, экономично в плане ресурсов.
можно было
Но ведь не сделано, правда? :) Или вы предлагаете аналог Qt с нуля написать?! :)
По хорошему, сейчас можно смотреть в сторону WASI, wgpu и всего такого. Все вместе это смогло бы вырасти в куда более универсальное и прикольное решение.
Можно языки разметки типа qml напрямую в wasm транслировать, а с хоста прокидывать нужные методы.
Ну дык Qt туда и смотрит: https://doc.qt.io/qt-5/wasm.html
Блин, самой либе уже 30 лет, это вот прямо говоря, очень много, очень очень. То, что они запускаются внутри wasm это круто, но они при этом тащат огромный техдолг вовнутрь.
когда скорости JS начинает не хватать — переносишь логику в C++
Есть надежда что WebAssembly позволит точно так же, но в html
Вы бы еще видео Антона Полухина здесь запостили.
Давайте с примерами, того, что можно запустить у себя на машине. Я начну.
Вот, скачайте(не надо выбирать онлайн) и кликните самый большой датасет. Поиграйтесь, посмотрите на зумы и прочие фишечки.
А потом вернитесь и покажите мне такой аналог на плюсах, но чтобы не тормозил.
dlsc.com/products/flexganttfx
Ведь это те самые локомотивы, что двигают прогресс.
Они как никто другой сталкиваются с проблемами, которые скрыты от какого-нибудь среднего разработчика.
И они как никто другой, должны понимать, на сколько сложно объективно измерять перформанс.
Но смотришь на комменты и некоторых индивидов и диву даешься.
Ведь сам javafx писан на плюсах, как и JVM. И те плюсовики, которые пишут JVM, от них редко услышишь подобного рода заявления. Ну то есть люди, которые создают продукты, которые реально двигают миллиардные бизнесы по миру.
А тут приходит «Вася из Ульяново» и рассказывает, как же джава тормозит, аж скулы сводит.
Без аргументов, без цифр, без примеров, без замеров. Человеческий фактор.
А тут приходит «Вася из Ульяново» и рассказывает, как же джава тормозит, аж скулы сводит.
Можно вопрос из зала? Вот смотрите. Есть чудесный проект Кассандра. Как известно, он на Джаве. Но его зачем-то переписывают на C++ — ScyllaDB. Если джава прекрасно, то зачем так делают? Все-таки, значит, есть проблемы в джаве и с перформансом, и с выделением памяти. И ребятки решили бороться с этим самым радикальным методом. Нет? Это не означает, что "джава тормозит". Это реально миф из бородатых времен. Но возможно, что есть типы задач, которые лучше делать тут, а другие типы задач — там.
Поэтому такие продукты появляются на джаве. Это быстрее и дешевле.
Когда нужен топ, то нужны или плюсы или раст и тогда переписывают.
Конечно, грамотная реализация на плюсах будет быстрее.
С такими очевидными вещами никто и не спорит. Вот питон реально медленный, тут мало что попишешь, но даже у него огромная ниша. Особенно в связке со всякими плюсовыми либами.
Сложно представить, что проблемы с performance, которые возможно затрагивают 1-5% кода, нельзя оформить доп. нативной библиотекой. А какой-нибудь менеджмент вообще не про performance.
Я подозреваю, основная причина все-таки embedded и AOT, который Java никак не расдуплится сделать с другими фишками типа Canadian Cross.
Сложно представить, что проблемы с performance, которые возможно затрагивают 1-5% кода, нельзя оформить доп. нативной библиотекой
Во многих приложениях это UI — 1-5% кода, а 95% делом занимается а не формочками :). И если на плюсах начинает жить логика (а это очень часто так для подобных приложений) то всё, хана, интерфейс быстро разрастается и становится непонятным, так что оказывается в разы проще UI на плюсах сделать. И в случае с Qt это вдобавок получается очень удобно, просто в разы удобнее того же C#. По части удобства какой-нибудь мелкой разработки где язык работает клеем между С++ библиотеками, на мой взгляд рулит Python. Там хорошо прототипы пишутся по принципу «все медленное пихаем в плюсовую библиотеку, всю логику оставляем в Python, для UI прикручиваем PyQt». С Java правда не работал (если не считать написания небольшого плагина для ImageJ) но по отзывам слышал (да и мне самому так показалось) что он плюс-минус на C# похож.
Конечно, я же и говорю, вы платите железом например. Ну и FFI здесь не единственная проблема. Урезанные версии джавы запускали на симкартах вроде. Но когда вы пишете на десктопной джаве, то как правило пишете разухабисто, с объектами, вот это все.
Трейдофф
У джавы больой throughput но малый latency. Я так понимаю это фундаментальный момент всех гц. Плюс джит на эмбеддед так себе надо полагать
Потому что, 1) JIT — который пока раскочегарится и соберет статистику 2) GC — может выпадать в ненужные моменты.
По сути если мерить кол-во http response в 1 минуту на заданное железе, то throughput будет одинаковый или лучше. А вот хвост 5-15% самых медленных запросов, будет гораздо хуже.
Поэтому по моему лучше форк (тем более, если KDAB готов вписаться), чем полных отказ от Qt и переход на Web, что есть полнейший бред для многих задач!
www.gnu.org/licenses/lgpl-3.0.en.html
Недавно встал выбор библиотеки для проекта, который должен быть «кросс». Выбор был между Qt, Java и «чем угодно ещё». Java не очень люблю (субъективно, хотя на 13 уже можно существовать), к тому же нужно было в любом случае писать код на плюсах для критичной к быстродействию части, а JNI — боль, так что его отбросил почти сразу. В Qt сомневался, поскольку не очень хорошо отзывались мои сотрудники о нём. В итоге погуглил, и понял, что у меня есть минимум ещё 2 варианта — SDL и wxWidgets. Присмотрелся ко второму (соблазнило использование нативных системных компонентов), и понял, что это «оно». С системой layout разобрался достаточно быстро, с быстродействием проблем нет — ибо native. С лицензированием глубоко не вкуривал, но вроде тоже всё спокойно.
Не знаю, может, мы с разработчиками «нашли друг друга», но в документацию пришлось вкуривать всего пару раз, на неочевидных названиях контролов и на тонкостях работы с OpenGL (адепты Вулкана — молчать, сам о нём знаю, но для первого прототипа юзал что умею). Остальное кодил на интуиции, и оно работает как задумано.
Насчёт отставания от стандарта — да, Qt не на bleeding edge развития C++, но подвижки идут. Например, тот же новый (относительно, ему уже несколько лет) синтаксис сигналов-слотов на указателях на функции, или отказ от собственных алгоритмов в пользу STL. Опять же, чтобы понять путь библиотеки, нужно "обуть ее обувь" — фреймворк появился в годы черти какой поддержки стандартов, единственным выходом было использование минимального и гарантированно подерживаемого подмножества языка. С тех пор все изменения в пользу новых стандартов предпринимаются с учётом всех поддерживаемых платформ!
Насчёт проникновения не только в GUI, но и логику, как Вы говорите — все же Qt это фреймворк, он и не позиционируется как библиотека, поэтому все логично. Т.е. предлагается некий скелет, некий подход к организации приложения, следуя которому можно реализовать что-то удобно и комфортно. Если идти против его идеологии, боль неизбежна.
Захотят закрыть фреймворк — закроютПолностью — не могут. У них контракт с KDE, по которому они обязаны открывать код не позднее чем через год после его появления под коммерческой лицензией.
В простейшем же случае это будет
Button {
Row {
Image {}
Text {}
}
}Те, кто говорят про 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 уже давно такая политика. Они постоянно балансируют между стремлением заработать денег и стремлением не потерять сообщество. И будут этим заниматься дальше. Такова их тяжелая доля. Устраивать по этому поводу истерики я бы не стал.
Button {
icon.source: "path/to/icon.png"
text: "Button"
display: Button.TextUnderIcon
}
Искаропки, естественно. Плюс ее можно дополнительно стилизовать. Ну а так да, способов просто миллион.
там слишком много экспертизы нужно, чтобы поддерживать и qml, и widgets, и moc, и кросс-платформенность, и qt coreМне кажется Вы недооцениваете сообщество. Люди коммитят в .NET Core, в Go, в VS Code, в K8S — там тоже многослойно.
Простите за дурацкий вопрос, но я хотел бы уточнить: вы недовольны тем, что владельцы Qt старательно уменьшают количество вариантов бесплатного использования Qt в закрытых коммерческих разработках и при этом держат слишком высокие цены на коммерческую версию Qt. Правильно я вас понял?
Если сейчас годами баги висят, то что там при политических пертурбациях дальше может получиться…
Так ведь Qt же открытый продукт, можно баги закрывать самостоятельно и отсылать патчи в апстрим.
Но, раз они висят годами, то можно предположить следующее: те, кто используют Qt забесплатно, мало отдают взамен. А тех денег, которые владельцы Qt собирают с покупателей коммерческих решений, недостаточно для увеличения штата разработчиков.
Соответственно, может быть движение в сторону зажимания гаек с тем, чтобы собрать больше денег, приведет к улучшению продукта?
PS. Сам я придерживаюсь точки зрения, что цена на коммерческую лицензию высоковата (раньше она была пониже). Но саму Qt следовало бы распространять всего под двумя лицензиями: GPL и коммерческой. По крайней мере в ситуации, пока Qt Group вынуждена сама зарабатывать на разработке Qt и не имеет богатого донора (как это было после покупки TrollTech фирмой Nokia).
Если у IDE нет базовой бесплатной версии, позволяющей создавать и коммерческие проекты, то такая IDE будет терять аудиторию.
И источник денег выберет первое.
Да, я могу править баги, писать свою виртуальную клавиатуру под Андроид, графики самостоятельно рисовать, чтобы «быть добропорядочным использователем библиотеки».
Но зачем мне это, если я просто могу использовать charts.js, отдать ему json из любого места, и пойти дальше?
Тут кто-то спрашивал про датагриды «не-Qt». Я вот специально в заметке указал, что я не буду в детали вдаваться, а то бодания начнутся до бесконечности. Потому что кому-то Ext JS надо, а кому-то onclick() на кнопку достаточно. И они друг друга понимать не будут. (Вон уже «Electron с PHP на борту» кто-то озвучил...)
Но именно там кроется одно из преимуществ веба: там всего — дофига и больше.
Ваша позиция понятна. При этом, полагаю, вы хотели бы, чтобы вам за вашу работу платили зарплату, а фирма, в которой вы работаете, продавала бы продукты и получала бы прибыль, а не раздавала бы свои разработки бесплатно? Это риторический вопрос, на него можно не отвечать.
Но именно там кроется одно из преимуществ веба: там всего — дофига и больше.
Ну, на эту тему существует и альтернативное мнение, с которым я, в принципе, согласен. Это пока тебе надо наколеночную поделку сделать в три строчки, веб выглядит привлекательно, а нужно будет что-то посложнее — и приплыли, и бесплатные npm-пакеты, про которые так изящно выразился автор комментария по ссылке выше, не помогут. Лично я с пониманием отношусь к стремлению Qt Company зарабатывать деньги, причем зарабатывать деньги не за счет OpenSource-энтузиастов, которые, даже если и не контрибутят напрямую в проект, то все равно дают определенную рекламу и экспертизу — примеры использования, примеры решения типичных проблем, а за счет тех, кто в свою очередь зарабатывает деньги за счет каких-то своих закрытых продуктов, сделанных на базе Qt, это честно и справедливо, потому что на эти деньги фреймворк по сути и развивается. Их ценовая политика — это уже отдельный вопрос, как и то, что они основной упор делают на IoT, embedded, automotive и так далее, и в первую очередь пилят там, но, видимо, там сейчас основные деньги.
Есть мнение что никак, просто неэффективный менеджмент уже выдохся придумывать где денег заработать и делает рандомные действия ну вдруг поможет.
КМК, паниковать рано. В любом случае, либо будет форк под более либеральной лицензией под эгидой тех же KDE или KDAB. Либо QtC будет вынуждена более лояльно относиться к сообществу.
Я, честно говоря, за форк, так как QtC ударилось в Automotive, QML и прочий Embedded, хотя от Qt, чтобы соответствовать времени, требуется совсем другое: полноценный веб/мобильный тулкит. А вот у тех же KDE есть Kirigami и большой ряд других вещей в KDE Frameworks, которые неплохо было бы включить в новый форк.
А насчёт перехода на другой стек технологий варианты есть: wxWidgets, Electron+JS, gtkmm и другие. Но торопиться пока не нужно, с Qt всё будет хорошо.
Как вариант — FPC/Лазарус, тот вообще бесплатный.
Фреймворки работают прямо внутри IDE, в пределах одного языка, и не требуют каких-то связок как Флаттер.
Между прочим, есть и движение «с обратной стороны»: веб-стартапы, написанные на PHP, разрастаются и начинают требовать быстрых компонентов на C++
Благо возможностей в современном PHP вынести часть кода в C-библиотеку достаточно, а с каждой новой версией будет ещё больше. Так что, велкам!
Для меня показателен пример с TreeView. В Qt Quick Controls 2 отсутствовал такой базовый компонент, как TreeView. А в Qt Quick Controls 1 он был, но данный набор компонентов для QML получает статус deprecated. И много лет этот компонент не создавался, и соответствующий «баг» висел несколько лет.
И вот несколько дней назад данный «баг» закрыли. Я так и не понял: предложенное решение официальное или нет. Но в любом случае решение будет не в составе основного пакета, а через Qt Marketplace. И не до конца понятна лицензия, но комментарий «Wait is this GPL only? (╯‵□′)╯︵┻━┻» о многом говорит. Соответственно для MIT проектов компонента TreeView в составе Qt Quick Controls 2 не будет, и раз баг закрыт, то Qt и не будет даже об этом думать.
В итоге я помучался, помучался, пособирал дистрибутив под мак ось бессонными ночами (ага, кросс-платформенность, но приложения еще и доставлять как-то надо) и в итоге написал все на вебе. Приложение у меня нетребовательное к ресурсам.
Допустим у меня есть CAD приложение, в котором GUI сделан на Qt. Как в нём можно заменить GUI на HTML/CSS/JS/PHP?
CAD — понятие растяжимое. Если это что-то типа OnShape, т.е. нужно непосредственное немедленное общение с пользователем, то PHP тут вообще будет лишним.
Каждая панель с кнопками это WEB-страница? Для каждого Message Box строится DOM, запускается интерпретатор и виртуальная машина?
Нет, конечно.
О Qt всё давно понятно: им не интересны все эти ваши мелкие софтины на 3.5 пользователя. Им надо продавать Qt в какой-нибудь автомотив или томограф, так, чтоб покупатель платил за сотню лицензий разработчиков следующую сотню лет. К этому и идут. Каждый может сам себе решать по пути ему с ними в этом или нет.
На счёт UI автор прав, что лучше HTML и CSS ничего уже человечество не придумает. Qt до него не дотягивает, и QML не дотягивает, и WPF не дотягивает. А больше и нет ничего. Значит, будет везде HTML и CSS. Вопрос вот только в том, зачем нам в этой связке дальше Javascript и PHP. А они не нужны. Нужен WebAssembly (на плюсах, на расте), у которого будет доступ к DOM, CSS и всей инфраструктуре браузера(аудио, видео, сеть, камера и т.д.). И вот мы получаем чистый, быстрый, нативный код в комбинации с мощной системой отображения. Профит!
они не нужны. Нужен WebAssembly (на плюсах, на расте), у которого будет доступ к DOM, CSS и всей инфраструктуре браузера(аудио, видео, сеть, камера и т.д.). И вот мы получаем чистый, быстрый, нативный код в комбинации с мощной системой отображения. Профит!
Вы раскрыли мотивы мозиллы. Стопудово свой браузер переписывают на расте именно для этого — чтоб хоть как-то потянуть конкуренцию с хромом (я попробовал интегрировать его в проект, но это песец — ресурсы улетают как в трубу)
пока что выглядит хуже альтернатив
с таким уровнем знаний и аргументации я спорить не могу
Да и дело никогда не было в виртуальной машине, а было в тормознутости парсинга текстовых форматов, динамической типизации, сборщика мусора и т.д. В васме всего этого нет.
Наличие GC (да и динамической типизации) ортогонально wasm — машине — есть реализации ЯП с GC, компилирующиеся в wasm =) Аллокатор все равно нужен.
В мире, где уязвимо все, железо, софт, вы предлагаете рассылать пользакам голый бинарь?
Вы же понимаете, что это не возможно? В любом случае, в вэбе, как в недоверенной среде, будет что-то, что можно засунуть в какую-то обертку. И эта обертка и есть вирутальная машина.
Тут нет альтернатив. Но это не так уж и плохо. Джава достаточно быстрая\энергоэффективная для большинства задач. И в ВАСМ можно сделать не хуже.
Джава достаточно быстрая\энергоэффективная для большинства задачПотому во многих областях от нее отказались =)
В мире, где уязвимо все, железо, софт, вы предлагаете рассылать пользакам голый бинарь?Запускать бинарь в песочнице дешевле, чем крутить интерпретатор виртуального кода.
Вот вам аргумент номер 1, дальше можно даже не ходить.
У пользователя может быть абсолютно не определенное железо.
Арм, РИСК5, МИПС, х86, под все будем один мультибинарь делать?
Или каждому пользаку будем рассылать под архитектуру его проца?
Васм это байт код, и его интерпретация и дальнейшая компиляция в нативный код происходит достаточно быстро, чтобы не заморачиваться на этом.
И я не могу понять вы против чего выступаете конкретно?
Джава например компилится в рантайме и местами очень даже не плохо.
Васм это байт код, и его интерпретация и дальнейшая компиляция в нативный код происходит достаточно быстро, чтобы не заморачиваться на этом.Отставить эротические фантазии! Тесты потребления памяти Явы есть у меня в публикациях.
Джава например компилится в рантайме и местами очень даже не плохо.Даже весьма неплохо, если вы можете подождать пару минуток старта на суперсервере.
А про риски, писки, мипсики я бы сначала проверил.
Ой, а память вы завезли грузовиком?
"А про риски, писки, мипсики я бы сначала проверил."
Ага, отлично. Давайте не будем думать наперед. Ведь таких проблем у человека ещё не было. Хотя уже сейчас их как минимум 3, где количество девайсов уходит за сотни миллионов.
По факту решения этой проблемы у вас нет, кроме попыток не очень удачно иронизировать.
Про память…
Там где нужен васм, проблем с памятью больше нет. На телефонах нынче и 16ГБ ставят. 4ГБ сейчас минимум на самых дешёвых устройствах.
Не увидел ни одного аргумента.
Вот вам мой. makepad.nl
Текстовый редактор, васм, летает у меня на телефоне aarch64 и на компе amd64.
В нативной версии без васм, не оставляет и надежды всяким vscode
На телефонах нынче и 16ГБ ставят. 4ГБ сейчас минимум на самых дешёвых устройствах.Производители одобряют. А то некоторые так пишут, что и на полгиговом устройстве всё работает.
Вы не сможете это никак обойти.
Сэндбоксинг, разные архитектуры и проче, прочее.
У вас выбор не слишком велик. Придется идти на компромиссы.
И они, по сравнению с голым веэбом(CSS+JS+HTML) выглядят очень и очень многообещающе.
После него, были сильные ломки на счет перформанса всего вот этого андроид мира.
Диковато было наблюдать, как до этого 600MHz и 256 озу могли держать полноценную вытесняющую многозадачность как на десткопе, на каких-то адских техпроцессах умудрялись жить примерно столько же и на микро аккуме в 1300mah.
А потом характеристики начали расти как на дрожжах.
А скайп тормозил все сильнее и сильнее.
Понимаешь, что мир немного пошел не туда. И ничего с этим поделать нельзя.
Но ничего страшного, покуда человек разумен, рано или поздно мы начнем думать про перформанс.
Так же как и про корону, когда упремся в потолок.
Это заложено в нас генетически. Идем по пути меньшего сопротивления.
Не так эффективно как могли бы )))
А как прекрасно работают жесты на N900
Все, которые одним пальцем, работали прекрасно. И мне как-то хватало.
Даже была попытка реализовать что-то похожее на двухпальцевые жесты (тот же зум). И оно даже как-то работало почти на уровне "можно пользоваться".
Упомянутый wholeman стилус и сейчас есть в некоторых аппаратах, но зато N900 можно было зимой спокойно пользовать пальцами в обычных перчатках, а не в каких-то специальных.
У N900 стилус был обычной палочкой с тоненьким кончиком, а сейчас это либо сосиска, либо что-то специфическое, некоторые вообще заряжать надо.
В перчатках тоже, но экран был маленьким, поэтому в них далеко не всегда было легко попасть. Наверное, частый кейс — ответ на звонок, там кнопки большие, но я обычно отвечал с гарнитуры, поэтому было неактуально.
Там где нужен васм, проблем с памятью больше нет.То то не затихает плач, что браузер выжирает всю память. Или васм нужен не там?
Посмотрел, wasm дает потери по скорости от 50% до 150% от натива. Плюс накладные на JIT машину (память).
На хабре тоже есть цифры оттуда, чтобы долго не смотреть видео.
Неплохо конечно (лучше JS), но ничего особенного. Выигрыш относительно JS легко объясним строгой типизацией и ручной аллокацией.
То то не затихает плач, что браузер выжирает всю память. Или васм нужен не там?
Ну тут уже началась подмена. Как вы думаете, сколько сейчас сайтов на васм?
Пользаки сейчас плачут не над васмом очевидно.
Неплохо конечно (лучше JS), но ничего особенного.
Не надо верить на слово или полагаться на чьи-то слова.
Откройте какой-нибудь gmail, в соседней вкладке makepad.nl и сравните память. Отличается на порядок.
Можно ли это назвать «но ничего особенного»
Вы слишком не объективны и эмоциональны в этом вопросе.
То исследование мир уже видел, и даже там conclusion такой:
«We identify the causes of these performance gaps, providing ac-tionable guidance for future optimization efforts.»
То есть работа на васм все еще ведется, так что не вижу тут причин для особого беспокойства.
JIT машину (память)
JIT это больше не про память, а про ЦПУ. Это по сути отложенные оптимизации, которые вы обычно делаете АОТ.
В случае АОТ знатно потребляется как память так и ЦПУ. Но в случае джита это не совсем так. Ибо, у вас могут быть участки, которые никогда не оптимизируются за ненадобностью.
Пользаки сейчас плачут не над васмом очевидно.Конечно они плачут не от васм, но в той области
Там где нужен васм, проблем с памятью больше нет.Я теряю логику ваших высказываний.
Проблема с памятью в браузерах таки есть.
Откройте какой-нибудь gmail, в соседней вкладке makepad.nl и сравните память.Сравню, когда будет две страницы со схожей функциональностью. Эти очевидно несравнимы.
И напомню исходный мой посыл, чтобы не отдаляться от темы.
Я теряю логику ваших высказываний.
Проблема с памятью в браузерах таки есть.
Видно, что теряете. Проблема в браузерах есть. Но вы не ищете источник этих проблем. Для вас важно доказать утверждение браузер=говно.
Потому, что только это утверждение, с которым никто никогда не спорил.
Но оно слишком поверхностное, чтобы это обсуждать на таком уровне.
Эти очевидно несравнимы.
Ну раз для вас это вызывает трудности, то я умываю руки. Можете считать, что я слился )
И телефон с 4ГБ рам за 8тр, сейчас норма. Так что не вижу с чем вы тут спорите.
Учитывая, что эти цифры растут уверенными темпами.
Ну и васм, по сравнению с современным вэбом памяти потребляет столько, что этим можно пренебречь.
Ну, пример с hello world, допустим, работает.
А возьмём реальное приложение. Где куча форм, контроллов, полей и т.д.
На qt — накидал в композере, обозвал — и дальше хоть на С++, хоть на python — оно просто работает. На маке, винде и линуксе.
А вот теперь вдруг захотелось, чтобы все эти контролы были в веб-приложении.
И так же всё летело и свистело, где надо.
Нажал клавишу в поле, ткнул мышкой в контрол или график — и на бэкэнде получил нужный сигнал/коллбэк, как будто это на десктопном приложении. Правильно среагировал, что нужно поправил — и оп-па, на фронтэнде то, что нужно, автоматом перерисовалось/отреагировало.
Тут уже достаточно очевидно, что статической странички, которую на сервере сгенерит php как в вашем примере и отправит — явно недостаточно. А на стороне пользователя интерактив подразумевает скрипты. Явно не на php, а на чём-то, что есть прямо сейчас под рукой, прямо там. Тут-то что делать?
И есть ли фреймворки для веба, чтоб так же накидать визуально контролов на форму, а потом по клику в браузере на кнопку тупо вызывался обработчик ON_CLICK в бэкенде, без всяких подробностей, как это "унутри" работает, но с возможностью туда углубиться, если вдруг что-то пошло не так?
Просто: 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, фреймворков много.
Qt — это действительно очень крутой продукт, за который сейчас обидно. Он, можно так сказать, опередил свой время, очень приятно и удобно расширил плюсы. Ребята проделали очень много работы, чтобы на этом стеке как можно реже стрелять себе в ногу, чтобы код был чистый, понятный, единообразный. Документация — одна из лучших, что вообще есть.
Но сейчас ребята, во-первых, поплыли в узкие специализации типа automotive, поэтому во фреймворке все реже и реже появляется что-то вкусное для обычного разработчика. Во-вторых, все, что появляется, имеет либо коммерческую лицензию, либо GPL. И иногда это прям супер абсурдно: Qt Network под LGPL, а Qt Network Authorization под GPL ¯\_(ツ)_/¯
Или, например, ребята делают неплохую штуку — Qt Http Server, могло бы расширить использование фреймфорка для веб-разработки, но тоже под GPL. Кому оно в таком виде нужно будет?
При таком раскладе кажется, что функционал фреймворка заморожен. Либо используй то, что уже давно есть, либо плати. И я бы без всяких проблем с удовольствием поддержал бы проект и купил для своих пет-проджектов коммерческую лицензию, если бы она стоила не космических $3950 на разработчика в год! Откуда они вообще такие цены взяли? В чем проблема сделать инди лицензию $10 на разраба в месяц, без платной поддержки и прочих сомнительных «плюшек»?
А все это, как кажется мне, губит как экосистему Qt, так и плюсов. Мало того, что на пятки плюсов наступают современные, более простые и безопасные языки (go в бэкенде, rust в системщине и т.д.), так еще и старые, проверенные временем инструменты вставляют палки в колеса. Зачем разработчику садится учить Qt, если завтра он опять поменяет политику лицензий, либо компания не сможет его потянуть по цене? А зачем учить плюсы, если можно что-то быстренько набросать на всяких веб-технологиях, как предлагает автор поста (а потом эти приложения жрут гигабайты памяти и тормозят)? В итоге может получится ситуация, когда только большой интерпрайз типа VAG и будет сидеть на фреймворке, пока кто-нибудь и там не решит его поменять на что-то другое. Ну, так и приходят концы таким проектам.
Что же, будем надеяться, что все будет хорошо, они как-то выправят свою политику лицензий и цен. Форк от KDE — это, конечно, хорошо, но, кажется, поддерживать большую кодовую базу Qt как минимум сложно и ресурсоёмко.
А в чем проблема с qt http server? GPL 2 и 3 не обязывает открывать исходники если все крутиться на ваших серверах.
Мне почему то это напомнило ситуацию с qnx, тоже была система для своего времени крутая. И также менеджмент загубил компанию… Интересно, продают ли ее сейчас. В некоторых вакансиях на Qt, проскакивает QNX, но это все оборонные предприятия
При продаже Qt, Матиас Этрих (основатель КДЕ) остался в Nokia, видимо что-то знал...
В п.4e LGPL указано на предоставление интрукций методом п.6 GPL.
При распространении через Play Store, смотрим в GPL на п.6d. Так что всё-таки без дополнительных запросов надо обеспечивать.
Если не через Play Store, я сделал оговорку в скобках выше.
На сервере может быть пароль на вход, или личный кабинет чтобы убедиться что пользователь получил ПО именно от васДа, если распространялось ПО таким же образом.
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
Т.е. если резюмировать, то можно выложить эти инструкции(вместе с бинарниками), например, на своем сайте, а ссылку на сайт указывать внутри приложения и в его описании на Play Store?
А, если учитывать, что apk файл по сути zip архив, в котором лежат Qt модули в виде *.so файлов, то снимает ли это обязанность дополнительно публиковать свои бинарники? Ведь у конечного пользователя уже есть все необходимое для замены Qt модулей.
only to the extent that such information is necessary to install and execute a modified version of the Combined Work
Т.е. если в инструкции указано как поменять LGPL-компоненты внутри (чего бы то ни было, что вы распространяете), то этого достаточно при динамическом связывании.
В общем, за пределами десктопов LGPL 3 – это большой геморрой очень неудобная лицензия, а про магазины приложений я даже и начинать не буду...
Тогда получается, что все не так уж и плохо с магазинами приложений?
Тогда получается, что все не так уж и плохо с магазинами приложений?
Тут серая зона. Вы не можете гарантировать, что кто-то из потребителей вашего приложения не будет использовать его устройстве, где заблокирована ручная установка из APK? Можно ли заставлять пользователя в таком случае публиковаться на Play Store? Что, если третье лицо (Google) откажет ему в публикации? И т.д. и т.п.
Автор смешал две разные проблемы:
- плохая лицензионная политика Qt
- падение спроса на десктоп-приложения, рост спроса на веб и мобилы, и, по факту, отсутствие решений для этого со стороны Qt
Первая проблема, как здесь уже неоднократно писали, решается переходом на Delphi. Но эту проблему не нужно решать, если принять во внимание вторую.
А здесь всё хуже. Лично я считаю, что на текущий момент веб-приложения принципиально не могут достичь того комфорта для пользователя, который могут обеспечить десктоп-приложения. Все эти трюки, которыми делается "как-бы-десктоп-ПО", трюками и остаются. На десктопе оконная система нативная, в вебе она эмулируется стилями и манипуляциями с DOM. На десктопе программа имеет полный доступ к оборудованию, в вебе — если только повезёт с браузером. Десктоп-приложение может работать в отсутствие сервера, а для веб это скорее исключение.
Но, с другой стороны, веб создаёт возможности, которых у десктопе не было — запуск без установки, не нужны обновления на машине клиента, единая серверная авторизация, единое место хранения данных без передачи клиенту коннекта к БД… Платная подписка на сервис, конечно же.
Поэтому веб ещё ждёт своего Qt — такого цельного решения, которое нативными средствами будет исполнять приложения в вебе. И в котором сигналы клиентской части будут дергать слоты бэка, например, без написания лишнего кода. И в котором сигнал об изменении данных в QAbstractItemModel на бэке заставит перерисоваться дерево на фронте.
Может это будет сделано на новом типе браузера, может он будет работать на QML или на другом подобном декларативном языке.
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, но я не измерял, если что:) И памяти оно тоже сожрёт. Для большого приложения вряд ли это будет критично, а вот для маленькой софтинки из пары окон и десятка кнопок — неприятно.
C++/Qt: пора валить?.