Сообщение Re[5]: Кто как изучал Qt? от 01.10.2015 21:09
Изменено 01.10.2015 21:10 EXL
Здравствуйте, Igore, Вы писали:
I>Здравствуйте, EXL, Вы писали:
EXL>>Зачем вам вообще нужен QtQuick/QML? Поясните пожалуйста этот момент. На мой взгляд эта технология ещё в статусе "proof-of-concept";
I>Ну, этой технологии уже лет 6 или 7, поэтому "proof-of-concept" она перешагнула.
Да, я знаю это. Однако, с ней были постоянно какие-то сложности и перетряхивания. Сначала, во времена когда Qt был собственностью Nokia, в Qt 4 был реализован Qt Quick 1, который мог использовать нативный метод рендеринга (и работал он очень-очень шустро, поскольку предполагалось его использование в мобильных телефонах). Потом, с релизом Qt 5, появился Qt Quick 2, который работал только через OpenGL(|ES) 2, при этом совместимость с Qt Quick 1 была сломана и разработчикам приложений на этой технологии пришлось поправлять их под новые стандарты. Далее, уже в Qt 5/Qt Quick 2 снова появились какие-то проблемы и несовместимости. Точно помню ситуацию, когда разработчики плакались в блогах (по-моему на хабре), сетуя на то, что их Qt Quick-приложения, которые использовали Qt 5.1 (или Qt 5.2, уже не помню), перестали корректно работать и даже собираться в Qt 5.3.
Я клоню к тому, что хоть технологии и достаточно много лет, понятие инструмента для серьёзной разработки она, на мой взгляд, так и не перешагнула.
Кто-нибудь может назвать популярные десктопные или мобильные приложения на Qt Quick под основные (iOS/Android/Windows/OS X/Linux) платформы? Я вот таких и не знаю даже. Отмечу лишь игру от Google Labs — VoltAir, да QML Creator от независимого разработчика. Но всё это несколько не то. Google Labs, помнится, тоже не в восторге от Qt Quick были.
Знаю лишь одно действительно популярное мобильное приложение, использующее Qt под Android — это 2GIS. Оно, кстати, отечественное, что не может не радовать. Всем рекомендую его попробовать. Но они вроде как не используют Qt Quick/QML, да и вообще у них не ванильный Qt, а его отдельный форк, который компания самостоятельно поддерживает; следовательно под пример это приложение не подходит.
Кроме того существует отдельный мир, где Qt Quick/QML активно используется. Это различные, малопопулярные мобильные OS, где он по сути основа всего интерфейса. Их множество: MeeGo, Ubuntu Mobile, Sailfish OS, BlackBerry OS и др. Однако, там тоже не ванильный Qt Quick, а обильно приправленный специальными OS-зависимыми компонентами.
Так что буду рад, если кто покажет интересные приложения на том Qt Quick, который сейчас разрабатывает и продвигает дочерняя компания Digia — The Qt Company.
EXL>>Поэтому, если вам требуется создать десктопное приложение с парой кнопочек, диалогами да полем ввода -- Qt Widgets ваш выбор. Вы избавляетесь от JavaScript-интерпретатора. Избавляетесь от десятков мегабайт библиотек, так как QtQuick/QML работает через OpenGL 2/OpenGL|ES 2, а поскольку реализация этих технологий в MS Windows оставляет желать лучшего, такую программу требуется снабдить специальными костылями от Qt-разработчиков: либо ANGLE, который будет транслировать OpenGL|ES в DirectX, либо LLVM openglsw32.dll, который будет заниматься программным рендерингом. Только таким образом будет достигнута корректная работа QtQuick/QML-приложения на какой-нибудь старой офисной машинке с давно устаревшей видеокарточкой. Всё это же, конечно, выливается в огромный размер дистрибутива программы, за 50МБ даже для простейшей кнопки или HelloWorld'а.
I>После выходя 5.5 это почти все неактуально. QML приложения теперь нормально отображаются через RDP
I>
Интересно, спасибо. Дело движется, что не может не радовать!
Но всё равно, разве из этого следует, что приложения "отвяжутся" от ANGLE или opengl32sw.dll на слабых конфигурациях? Как я понимаю, с -opengl dynamic алгоритм выбора метода рендеринга при запуске приложения будет следующий:
А потому библиотеки всё-таки придётся "докинуть".
А ещё тут прочитал, что в официальных сборках Qt 5.5 под Windows наконец-то библиотека QtCore стала свободна от зависимости жирнейших ICU-библиотек (~30MB).
Оказывается, это у них баг на билд-ферме был с момента выпуска Qt 5.0.0 тянущийся. Вот ведь как бывает. https://bugreports.qt.io/browse/QTBUG-38259
I>Здравствуйте, EXL, Вы писали:
EXL>>Зачем вам вообще нужен QtQuick/QML? Поясните пожалуйста этот момент. На мой взгляд эта технология ещё в статусе "proof-of-concept";
I>Ну, этой технологии уже лет 6 или 7, поэтому "proof-of-concept" она перешагнула.
Да, я знаю это. Однако, с ней были постоянно какие-то сложности и перетряхивания. Сначала, во времена когда Qt был собственностью Nokia, в Qt 4 был реализован Qt Quick 1, который мог использовать нативный метод рендеринга (и работал он очень-очень шустро, поскольку предполагалось его использование в мобильных телефонах). Потом, с релизом Qt 5, появился Qt Quick 2, который работал только через OpenGL(|ES) 2, при этом совместимость с Qt Quick 1 была сломана и разработчикам приложений на этой технологии пришлось поправлять их под новые стандарты. Далее, уже в Qt 5/Qt Quick 2 снова появились какие-то проблемы и несовместимости. Точно помню ситуацию, когда разработчики плакались в блогах (по-моему на хабре), сетуя на то, что их Qt Quick-приложения, которые использовали Qt 5.1 (или Qt 5.2, уже не помню), перестали корректно работать и даже собираться в Qt 5.3.
Я клоню к тому, что хоть технологии и достаточно много лет, понятие инструмента для серьёзной разработки она, на мой взгляд, так и не перешагнула.
Кто-нибудь может назвать популярные десктопные или мобильные приложения на Qt Quick под основные (iOS/Android/Windows/OS X/Linux) платформы? Я вот таких и не знаю даже. Отмечу лишь игру от Google Labs — VoltAir, да QML Creator от независимого разработчика. Но всё это несколько не то. Google Labs, помнится, тоже не в восторге от Qt Quick были.
Знаю лишь одно действительно популярное мобильное приложение, использующее Qt под Android — это 2GIS. Оно, кстати, отечественное, что не может не радовать. Всем рекомендую его попробовать. Но они вроде как не используют Qt Quick/QML, да и вообще у них не ванильный Qt, а его отдельный форк, который компания самостоятельно поддерживает; следовательно под пример это приложение не подходит.
Кроме того существует отдельный мир, где Qt Quick/QML активно используется. Это различные, малопопулярные мобильные OS, где он по сути основа всего интерфейса. Их множество: MeeGo, Ubuntu Mobile, Sailfish OS, BlackBerry OS и др. Однако, там тоже не ванильный Qt Quick, а обильно приправленный специальными OS-зависимыми компонентами.
Так что буду рад, если кто покажет интересные приложения на том Qt Quick, который сейчас разрабатывает и продвигает дочерняя компания Digia — The Qt Company.
EXL>>Поэтому, если вам требуется создать десктопное приложение с парой кнопочек, диалогами да полем ввода -- Qt Widgets ваш выбор. Вы избавляетесь от JavaScript-интерпретатора. Избавляетесь от десятков мегабайт библиотек, так как QtQuick/QML работает через OpenGL 2/OpenGL|ES 2, а поскольку реализация этих технологий в MS Windows оставляет желать лучшего, такую программу требуется снабдить специальными костылями от Qt-разработчиков: либо ANGLE, который будет транслировать OpenGL|ES в DirectX, либо LLVM openglsw32.dll, который будет заниматься программным рендерингом. Только таким образом будет достигнута корректная работа QtQuick/QML-приложения на какой-нибудь старой офисной машинке с давно устаревшей видеокарточкой. Всё это же, конечно, выливается в огромный размер дистрибутива программы, за 50МБ даже для простейшей кнопки или HelloWorld'а.
I>После выходя 5.5 это почти все неактуально. QML приложения теперь нормально отображаются через RDP
I>
I>https://wiki.qt.io/New_Features_in_Qt_5.5I>Windows packages are all built with -opengl dynamic. No OpenGL-only or ANGLE-only builds are provided anymore.
Интересно, спасибо. Дело движется, что не может не радовать!
Но всё равно, разве из этого следует, что приложения "отвяжутся" от ANGLE или opengl32sw.dll на слабых конфигурациях? Как я понимаю, с -opengl dynamic алгоритм выбора метода рендеринга при запуске приложения будет следующий:
- Try opengl32 and check if OpenGL 2.0 functions are available.
If this fails, try ANGLE.
If initialization fails either due to missing ANGLE libraries or some other reason, try opengl32sw.dll. In practice this will be a software rasterizer based implementation. To make it easy to get started, a pre-built version of Mesa llvmpipe is bundled with the binary packages of Qt 5.4.
А потому библиотеки всё-таки придётся "докинуть".
А ещё тут прочитал, что в официальных сборках Qt 5.5 под Windows наконец-то библиотека QtCore стала свободна от зависимости жирнейших ICU-библиотек (~30MB).
Оказывается, это у них баг на билд-ферме был с момента выпуска Qt 5.0.0 тянущийся. Вот ведь как бывает. https://bugreports.qt.io/browse/QTBUG-38259
Re[5]: Кто как изучал Qt?
Здравствуйте, Igore, Вы писали:
I>Здравствуйте, EXL, Вы писали:
EXL>>Зачем вам вообще нужен QtQuick/QML? Поясните пожалуйста этот момент. На мой взгляд эта технология ещё в статусе "proof-of-concept";
I>Ну, этой технологии уже лет 6 или 7, поэтому "proof-of-concept" она перешагнула.
Да, я знаю это. Однако, с ней были постоянно какие-то сложности и перетряхивания. Сначала, во времена когда Qt был собственностью Nokia, в Qt 4 был реализован Qt Quick 1, который мог использовать нативный метод рендеринга (и работал он очень-очень шустро, поскольку предполагалось его использование в мобильных телефонах). Потом, с релизом Qt 5, появился Qt Quick 2, который работал только через OpenGL(|ES) 2, при этом совместимость с Qt Quick 1 была сломана и разработчикам приложений на этой технологии пришлось поправлять их под новые стандарты. Далее, уже в Qt 5/Qt Quick 2 снова появились какие-то проблемы и несовместимости. Точно помню ситуацию, когда разработчики плакались в блогах (по-моему на хабре), сетуя на то, что их Qt Quick-приложения, которые использовали Qt 5.1 (или Qt 5.2, уже не помню), перестали корректно работать и даже собираться в Qt 5.3.
Я клоню к тому, что хоть технологии и достаточно много лет, понятие инструмента для серьёзной разработки она, на мой взгляд, так и не перешагнула.
Кто-нибудь может назвать популярные десктопные или мобильные приложения на Qt Quick под основные (iOS/Android/Windows/OS X/Linux) платформы? Я вот таких и не знаю даже. Отмечу лишь игру от Google Labs — VoltAir, да QML Creator от независимого разработчика. Но всё это несколько не то. Google Labs, помнится, тоже не в восторге от Qt Quick были.
Знаю лишь одно действительно популярное мобильное приложение, использующее Qt под Android — это 2GIS. Оно, кстати, отечественное, что не может не радовать. Всем рекомендую его попробовать. Но они вроде как не используют Qt Quick/QML, да и вообще у них не ванильный Qt, а его отдельный форк, который компания самостоятельно поддерживает; следовательно под пример это приложение не подходит.
Кроме того существует отдельный мир, где Qt Quick/QML активно используется. Это различные, малопопулярные мобильные OS, где он по сути основа всего интерфейса. Их множество: MeeGo, Ubuntu Mobile, Sailfish OS, BlackBerry OS и др. Однако, там тоже не ванильный Qt Quick, а обильно приправленный специальными OS-зависимыми компонентами.
Так что буду рад, если кто покажет интересные приложения на том Qt Quick, который сейчас разрабатывает и продвигает дочерняя компания Digia — The Qt Company.
EXL>>Поэтому, если вам требуется создать десктопное приложение с парой кнопочек, диалогами да полем ввода -- Qt Widgets ваш выбор. Вы избавляетесь от JavaScript-интерпретатора. Избавляетесь от десятков мегабайт библиотек, так как QtQuick/QML работает через OpenGL 2/OpenGL|ES 2, а поскольку реализация этих технологий в MS Windows оставляет желать лучшего, такую программу требуется снабдить специальными костылями от Qt-разработчиков: либо ANGLE, который будет транслировать OpenGL|ES в DirectX, либо LLVM openglsw32.dll, который будет заниматься программным рендерингом. Только таким образом будет достигнута корректная работа QtQuick/QML-приложения на какой-нибудь старой офисной машинке с давно устаревшей видеокарточкой. Всё это же, конечно, выливается в огромный размер дистрибутива программы, за 50МБ даже для простейшей кнопки или HelloWorld'а.
I>После выходя 5.5 это почти все неактуально. QML приложения теперь нормально отображаются через RDP
I>
Интересно, спасибо. Дело движется, что не может не радовать!
Но всё равно, разве из этого следует, что приложения "отвяжутся" от ANGLE или opengl32sw.dll на слабых конфигурациях? Как я понимаю, с -opengl dynamic алгоритм выбора метода рендеринга при запуске приложения будет следующий:
А потому библиотеки всё-таки придётся "докинуть". Вот если бы оно во втором пункте начало рендерить в GDI, как в Qt Quick 1, это было бы идеологически правильный путь для MS Windows.
А ещё тут прочитал, что в официальных сборках Qt 5.5 под Windows наконец-то библиотека QtCore стала свободна от зависимости жирнейших ICU-библиотек (~30MB).
Оказывается, это у них баг на билд-ферме был с момента выпуска Qt 5.0.0 и тянулся вплоть до момента выпуска Qt 5.5.0. Вот ведь как бывает. https://bugreports.qt.io/browse/QTBUG-38259
I>Здравствуйте, EXL, Вы писали:
EXL>>Зачем вам вообще нужен QtQuick/QML? Поясните пожалуйста этот момент. На мой взгляд эта технология ещё в статусе "proof-of-concept";
I>Ну, этой технологии уже лет 6 или 7, поэтому "proof-of-concept" она перешагнула.
Да, я знаю это. Однако, с ней были постоянно какие-то сложности и перетряхивания. Сначала, во времена когда Qt был собственностью Nokia, в Qt 4 был реализован Qt Quick 1, который мог использовать нативный метод рендеринга (и работал он очень-очень шустро, поскольку предполагалось его использование в мобильных телефонах). Потом, с релизом Qt 5, появился Qt Quick 2, который работал только через OpenGL(|ES) 2, при этом совместимость с Qt Quick 1 была сломана и разработчикам приложений на этой технологии пришлось поправлять их под новые стандарты. Далее, уже в Qt 5/Qt Quick 2 снова появились какие-то проблемы и несовместимости. Точно помню ситуацию, когда разработчики плакались в блогах (по-моему на хабре), сетуя на то, что их Qt Quick-приложения, которые использовали Qt 5.1 (или Qt 5.2, уже не помню), перестали корректно работать и даже собираться в Qt 5.3.
Я клоню к тому, что хоть технологии и достаточно много лет, понятие инструмента для серьёзной разработки она, на мой взгляд, так и не перешагнула.
Кто-нибудь может назвать популярные десктопные или мобильные приложения на Qt Quick под основные (iOS/Android/Windows/OS X/Linux) платформы? Я вот таких и не знаю даже. Отмечу лишь игру от Google Labs — VoltAir, да QML Creator от независимого разработчика. Но всё это несколько не то. Google Labs, помнится, тоже не в восторге от Qt Quick были.
Знаю лишь одно действительно популярное мобильное приложение, использующее Qt под Android — это 2GIS. Оно, кстати, отечественное, что не может не радовать. Всем рекомендую его попробовать. Но они вроде как не используют Qt Quick/QML, да и вообще у них не ванильный Qt, а его отдельный форк, который компания самостоятельно поддерживает; следовательно под пример это приложение не подходит.
Кроме того существует отдельный мир, где Qt Quick/QML активно используется. Это различные, малопопулярные мобильные OS, где он по сути основа всего интерфейса. Их множество: MeeGo, Ubuntu Mobile, Sailfish OS, BlackBerry OS и др. Однако, там тоже не ванильный Qt Quick, а обильно приправленный специальными OS-зависимыми компонентами.
Так что буду рад, если кто покажет интересные приложения на том Qt Quick, который сейчас разрабатывает и продвигает дочерняя компания Digia — The Qt Company.
EXL>>Поэтому, если вам требуется создать десктопное приложение с парой кнопочек, диалогами да полем ввода -- Qt Widgets ваш выбор. Вы избавляетесь от JavaScript-интерпретатора. Избавляетесь от десятков мегабайт библиотек, так как QtQuick/QML работает через OpenGL 2/OpenGL|ES 2, а поскольку реализация этих технологий в MS Windows оставляет желать лучшего, такую программу требуется снабдить специальными костылями от Qt-разработчиков: либо ANGLE, который будет транслировать OpenGL|ES в DirectX, либо LLVM openglsw32.dll, который будет заниматься программным рендерингом. Только таким образом будет достигнута корректная работа QtQuick/QML-приложения на какой-нибудь старой офисной машинке с давно устаревшей видеокарточкой. Всё это же, конечно, выливается в огромный размер дистрибутива программы, за 50МБ даже для простейшей кнопки или HelloWorld'а.
I>После выходя 5.5 это почти все неактуально. QML приложения теперь нормально отображаются через RDP
I>
I>https://wiki.qt.io/New_Features_in_Qt_5.5I>Windows packages are all built with -opengl dynamic. No OpenGL-only or ANGLE-only builds are provided anymore.
Интересно, спасибо. Дело движется, что не может не радовать!
Но всё равно, разве из этого следует, что приложения "отвяжутся" от ANGLE или opengl32sw.dll на слабых конфигурациях? Как я понимаю, с -opengl dynamic алгоритм выбора метода рендеринга при запуске приложения будет следующий:
- Try opengl32 and check if OpenGL 2.0 functions are available.
If this fails, try ANGLE.
If initialization fails either due to missing ANGLE libraries or some other reason, try opengl32sw.dll. In practice this will be a software rasterizer based implementation. To make it easy to get started, a pre-built version of Mesa llvmpipe is bundled with the binary packages of Qt 5.4.
А потому библиотеки всё-таки придётся "докинуть". Вот если бы оно во втором пункте начало рендерить в GDI, как в Qt Quick 1, это было бы идеологически правильный путь для MS Windows.
А ещё тут прочитал, что в официальных сборках Qt 5.5 под Windows наконец-то библиотека QtCore стала свободна от зависимости жирнейших ICU-библиотек (~30MB).
Оказывается, это у них баг на билд-ферме был с момента выпуска Qt 5.0.0 и тянулся вплоть до момента выпуска Qt 5.5.0. Вот ведь как бывает. https://bugreports.qt.io/browse/QTBUG-38259