Pull to refresh

Comments 43

Выскажу пару моментов.

  1. WebEngine — это круто, но жаль, что версия под MinGW в пролете. А Webkit убрали. Ничего не оставив под MinGW.
  2. "Qt Script объявлен устаревшим и пользователям рекомендуется перейти на Qt QML". Может я не понял, но разве не QJSEngine его заменяет?
  3. Но я думаю, что очень многие гораздо с большим нетерпением ждут 5.7, где обещают очень много вкусного.
Чем вам JavaScript в QJSEngine не устраивает?
Ничем) Просто написано, что заменяется Qt QML, а вроде QJSEngine.
На самом деле это очень спорное решение, вот здесь обсуждалось: forum.qt.io/topic/52306/qt-5-5-qt-script-deprecated-what-is-replacement, (к сожалению после того как Qt сделало merge аккаунтов, мои комментарии там стали просто под серым невидимкой =)), это заблуждение думать что QJSEngine везде и всегда заменяет легковесный и отлично интегрированный QtScript. Я применял его в проектах не имеющих ничего общего с QML начиная еще с Qt 3.* — там он был еще не не ECMA совместимый, но кстати тоже отлично читаемый с С++ подобным синтаксисом.

Не всегда и не везде есть/нужно тащить за собой V8 реализацию если просто требуется какую то несложную обвязку вынести «наружу» в скрипт.

Я приводил пример в этом топике, он отлично подходил, например для описывания правил фильтрации/сортировки в моделях, построенных на коллекциях QObject-ов…
Да, Вы правы, но это не меняет сути… QtScript был очень легковесной, при этом достаточно стабильной реализацией, который не требовал вообщем то ничего, чтобы его использовать… тут на самом деле "все стороны правы", но только в данном случае Qt применяется такой широкой массой разработчиков и в таком широком спектре задач, что правда у каждого будет своя, ну и в конечном итоге решать все равно будут те кто у руля..
а что вкусненького в 5.7 ожидается?
https://wiki.qt.io/New_Features_in_Qt_5.7

Они многие модули, например, которые были в коммерческой версии, добавят в Open Source версию. Те же графики, наконец, появятся.
Разговаривал на QT Dev 2015 в Берлине с разработчиком WebEngine, услышал много вздохов и увидел много печали в глазах, но вменяемого ответа о том — зачем выпиливать отлично интегрированный Веб движек, прекрасно положенный в инфраструктуру Qt и используемый в очень большом количестве десктопных бизнес приложений и впиливать нечто даже функционально не всегда совместимое не услышал…

Сравните степень интеграции WebKit с поддержкой native QNetworkAcessManager, QNetworkRequest, QNetworkReply, полностью контролируемого и использующего стандартный для Qt транспортный уровень и сравните с текущим состоянием WebEngine… где ряд вещей просто технически пока не переносятся, вне зависимости от размера бубна…

По сути последние годы развития Qt это путь в мобильные платформы и понятно что сделать обертку на native webview для каждой из платформ в текущем виде WebEngine гораздо проще чем через интерфейсы WebView, но господа Qt-шники, мир крутится не только вокруг embedded и mobile и есть огромное количество enterprise приложений где новое не всегда лучше хорошо работающего старого…
Коллега ходил на тренинг от Digia по Qt, и там высказались что теперь стараются заработать на embedded, а не на Desktop'e.
Наверное поэтому они для некоторых компонентов(Чарты, клавиатура и т.д.) поменяли лицензии. Хорошо или плохо вопрос сложный(хорошо или плохо, что появились Qt Charts, Qt Data Visualization и т.д.)
ну я двумя руками "за" что развивается что то новое и прогрессивное, мне очень нравится QML и я могу представить себе очень много разных его применений, и на десктопе в том числе… но если посмотреть например success story того же KDAB, там очень много enterprise применений, исключительно widget-ных, и забывать про них, на мой взгляд не правильно… мне сложно судить на чем они реально зарабатывают, но мне кажется что будет печально если Qt прошагает дорогой Нокии… а компоненты которые Вы привели в пример, действительно классные… но при этом опустившись на небо и посмотрев в исходники например чего то более базового… например TableView, можно увидеть массу "костылей"…
QJSEngine, да. Но входит оно в модуль Qt Qml. Поэтому, QScriptEngine -> QJSEngine, Qt Script -> Qt QML.
Спасибо за разъяснение!
А модуль Qt Charts доступен в этом релизе в бесплатной лицензии? Вроде я что-то такое слышал, что этот компонент должен стать доступным в бесплатной лицензии, начиная с какого-то релиза. Сейчас он входит в Qt Commercial.
В следующей итерации так и будет. В 5.7. В 5.6 еще нет.
Потратил пару дней на попытку перехода до 5.6.0 и скажу что там еще много багов.
При статик сборке никак не получается скомпилировать или отключить FreeType.
В нетронутых сборках с официального сайта использование addBindValue в MySQL приводит к ошибке "QMYSQL3: Unable to fetch data", хотя все прекрасно работает в 5.5.1.
Подозреваю там еще много подводных камней которые нуждаются в фиксах.
Так что ждем 5.6.1
Далеко не все исправления вошли в 5.6.0. Возможно, давно уже исправлено, но пока только в гите. Ну а если в гите нет — вы знаете, что делать ;)
Там уже не один мой баг репорт.
Времени не всегда хватает на копания и поиски решений, а тем более ждать когда пофиксят их на багтрекере.
Я о том что с версиями х.х.0 всегда больше времени на переход уходит, и что проще пропустить их, подождать х.х.1 версию.
Небольшое уточнение: под MSVS 2008 эта версия не собирается и в supported platforms её нет. Нужна, как минимум десятая студия.
Собственно, официально MSVS2008 не поддерживается в Qt5 уже давно (если такое вообще было), но 5.5.1 ещё можно было собрать без особых проблем, а в этой сломалось что-то основательное.
Вставлю свои 5 копеек. У меня как раз появился монитор 4К и появилась возможность проверить что там и как. Могу сказать, что багов неприлично много. Некоторые баги не фиксятся годами. Вот например я делал репорт:
bugreports.qt.io/browse/QTBUG-36825
Два года прошло, но не исправлено, хотя по сути если уж заявили поддержку highdpi, то какбэ надо. В 5.6.0 с багами отображается тема Windows к примеру.
Такое чувство, что они поувольняли всех тестеров или просто переориентировались на что-то другое… Qml, мобильная разработка. Однако, я считаю что Qt для десктопа достаточно актуальна, ибо замены я не вижу.
У меня коммерческая лицензия и я связывался с разработчиками насчет приоритетного фикса багов, однако получил ответ, что у коммерческих юзеров нет привилегий в этом вопросе. Подскажите кто в курсе, а если сделать динамическую сборку (dll библиотеки отдельно), то можно ли для коммерческих проектов использовать OpenSource вариант? Потому что платить уже чета не хочется на самом деле.
HighDPI это реально головняк… да, они сделали поддержку в ресурсах иконок @2, @3 итд, что в принципе конечно уже шаг вперед, но этого мало… QT_AUTO_SCREEN_SCALE_FACTOR безбожно крив для любого размера шрифта > 100% (Windows)… каких то разумных workaround не предложено… полностью с Вами согласен и уже тоже писал выше… приоритеты сменились… мобильные платформы и QML ориентированный на Full Screen для различных мобильных устройств… для десктопа QML очень интересная штука, но судя по опять же имеющимся и годами не исправляемым багам там просто все болт положили на десктоп..
Зато есть время вот на это:
https://bugreports.qt.io/browse/QTCREATORBUG-15727
Я очень опасаюсь, что они повторят судьбу Дельфи. Был же хороший инструмент, потом его 10 раз перепродали, потом они пытались объять необъятное, наплодили кучу глючных версий за достаточно приличные деньги. В свое время убежал на Qt и чет чую, что тут те же вилы:) Может пора учить C# и Xamarin? :)
Я очень опасаюсь, что они повторят судьбу Дельфи.

Может да, а может и нет. Qt имеет Open Source версию, которой владеет сообщество KDE Free Qt Foundation.
Кстати про HighDPI. При включении поддержки данного режима обычные компоненты становятся нормальными, но контролы становятся огромными. Без включения оного компоненты нормальные, а обычные элементы мелкие.
QQC1 начали подстраиваться под плотность точек на экране значительно раньше. Но, они не дружат с Auto HiDPI Scaling, и скорее всего не будут :(
А вот QQC2 как раз под Auto HiDPI Scaling заточены.
Огромное спасибо! Вот в чем дело то!
А случайно не знаете, в новых контролах главное меню и таблицы реализованы?
На меню под WinXX я бы не рассчитывал, оно работает настолько медленно что стыдно показывать, баг висит, как обычно на него положено...
Если MenuBar — то это QQC1. Таблицы и TreeView там же. Но можно и в QQC2 сделать свой MenuBar и запихнуть в ApplicationWindow.header. Кстати, в QQC2 попап (а значит и меню) не является окном.
Можно. Но начиная с Qt 5.7, некоторые новые модули будут под GPL3, так что зависит от используемых модулей.
Впрочем, есть мнение, что можно и статически, если предоставлять также объектные файлы, чтобы была возможность пересобрать программу с новой версией библиотеки.
На iOS желательно иметь коммерческую версию.
Ну у меня модули "core gui widgets xml network printsupport". В будущем надо будет делать поддуржку мобильных платформ. Вот тоже дилемма. То ли юзать qml и весь интерфейс переписать, то ли чета другое попробовать.
"На iOS желательно иметь коммерческую версию."
А с чем это связано?
С тем, что условия AppStore несовместимы со свободным ПО.
В какой части несовместимы? Клиент Telegram же там есть.
И что с того, что он там есть? :)
Уточню, что под свободными я имею в виду копилефтные. Несовместимы в той части, что лицензия AppStore накладывает дополнительные ограничения на использование и распространение ПО.
Мало ли что вы имеете в виду под "свободными". Копилефт — как раз НЕ свободная лицензия.
Хорошая попытка, но нет. Я немного разбираюсь в теме и знаю, что копилефтные лицензии являются свободными. А в BSD-сраче участвовать желания нет.
Sign up to leave a comment.

Articles