Компания Digia совместно с сообществом Qt Project представила (http://www.digia.com/ru/Digia/1/News/It-is-here-Qt-50-Beta-h.../) бета-версию Qt 5.0 (http://www.qt-project.org/wiki/Qt-5-Beta), первого значительного выпуска за последние семь лет, развиваемого при непосредственном участии сообщества в рамках нового полностью открытого процесса (http://www.opennet.me/opennews/art.shtml?num=32103) разработки и управления проектом. Несмотря на ряд существенных улучшений и изменений, Qt 5 сохраняет базовую обратную совместимость с прошлыми выпусками (удалён ряд давно устаревших элементов), поддерживает в полной мере средства для создания Qt-программ на языке C++ и содержит почти все компоненты Qt 4, большинство модулей из бывшего Qt Mobility и некоторые экспериментальные элементы из Qt Labs.
Из новых веяний (http://labs.qt.nokia.com/2012/08/30/qt-5-beta-is-here/) в Qt 5 можно отметить смещение акцента в сторону использования для написания приложений средств декларативного описания интерфейса с определением логики взаимодействия с пользователем на языке JavaScript, в то время как применение C++ позиционируется для реализации критичных ко времени выполнения или излишне сложных частей программы, а также для создания новых модульных бэкендов для Qt Quick.
Ключевые изменения Qt 5:
- Модульная структура (http://www.opennet.me/opennews/art.shtml?num=28425) репозитория. Многие из подсистем Qt разрабатываются разными группами разработчиков, развиваются с повышенной интенсивностью или плотно зависят от сторонних проектов. При грамотном разбиении фреймворка на модули, подобные подпроекты смогут обновляться и поставляться независимо от других частей Qt. Модульная организация репозитория позволит обеспечить сборку отдельных библиотек без загрузки и пересборки всех зависимостей, а также независимое использование каждой библиотеки, т.е. в разработчики получат возможность обособлено использовать только те компоненты Qt, которые им необходимы. Разработчики интенсивно развивающихся подсистем QtWebKit и QtDeclarative получат возможность не ждать когда подтянется другой код и выпускать релизы значительно чаще. Кроме того, модульная структура существенно упростит приём в состав Qt модулей, созданных сторонними проектами, например, проект KDE намерен добиваться интеграции в Qt некоторых своих библиотек общего назначения. Ожидается, что разбиение на модули будет длительным и постепенным процессом, который будет продолжен и после выхода Qt 5.0.
- Перевод всех портов на использование уровня абстракции Qt Platform Abstraction layer (QPA), основанного на наработках проекта Lighthouse (http://labs.qt.nokia.com/category/labs/lighthouse/). QPA значительно упрощает перенос Qt на новые оконные системы и устройства, так как он изначально оперирует более абстрактными категориями, фундаментально отличаясь от ранее используемых средств интеграции с оконными системами. Например, уже написаны бэкенды для QNX, Android и iOS. В настоящее время реализация QPA уже входит в состав Qt 4.8, в качестве замены QWS/Qt Embedded, но в Qt 5 данная прослойка будет задействована для всех платформ, что потребовало существенно переработки огромной части кода, связанного с обеспечением поддержки различных платформ. Из полностью поддерживаемых бета-версией платформ отмечены: X11/Linux, Windows, Mac OS X, Embedded Linux и Windows Embedded.
- Изменение архитектуры графического стека и увеличение производительности графических операций. В качестве центрального элемента новой архитектуры для Qt Quick выступает QML Scenegraph, работающий поверх OpenGL. Для работы новой графической архитектуры Qt 5 система должна поддерживать как минимум OpenGL (ES) 2.0. В качестве примера производительности Qt 5 приводится способность вывода контента со скоростью 60 кадров в секунду на одноплатном компьютере Raspberry Pi.
Поддержка QPainter сохранена для выполнения расширенных функций, но ограничена возможностью использования бэкенда программной растеризации вывода (Raster), бэкенда OpenGL и бэкенда для вывода на печать и создания PDF. Поддержка привязанных к платформам бэкендов, таких как X11 и CoreGraphics, прекращена. QWidgets теперь отображается поверх графической сцены, а не наоборот, как реализовано в версии Qt 4, что позволило перейти в Qt 5 на принципиально новую графическую архитектуру, сохранив при этом совместимость с Qt 4.
В QtGui добавлен набор классов QOpenGL*, заменивших собой устаревшие классы QGL*, которые пока оставлены для обеспечения совместимости. Также представлен класс QGuiApplication, которые заметно легче классов QApplication и QWindow при выполнении задач обработки корневой области на экране.
- Выделение всех связанных с QWidget возможностей в отдельную библиотеку. Несмотря на то, что основанные на QWidget классы чрезвычайно важны для существующих приложений, общая тенденция ведёт к тому, что все пользовательские интерфейсы должны быть реализованы на QML и Qt Quick. Отделение связанных с QWidget функций в отдельную библиотеку позволит в долгосрочной перспективе сохранить чистоту архитектуры Qt 5.- Переработанная реализация Qt Quick 2, которая разделена на отдельные модули, связанные с графической частью и с компонентами поддержки языков QML и JavaScript. Обеспечивающие выполнение JavaScript классы (QJSEngine и QJSValue) теперь базируются на JavaScript-движке V8, развиваемом при участии компании Google и распространяемом под лицензией BSD. В движок QML также внесены значительные оптимизации производительности и связанные с языком улучшения, при сохранении базовой совместимости. Модуль Qt Quick включает в себя реализацию Scenegraph на базе OpenGL и все ранее поддерживаемые в Qt 4.x базовые возможности. Дополнительно добавлена поддержка графических эффектов, создаваемых при помощи шейдеров OpenGL. Для обеспечения обратной совместимости в виде модуля Qt Quick 1 будет поставляться полностью совместимая с Qt 4.x реализация Qt Quick.
URL: http://www.digia.com/ru/Digia/1/News/It-is-here-Qt-50-Beta-h.../
Новость: http://www.opennet.me/opennews/art.shtml?num=34701
Ну наконец-то! Надоело снапшоты тянуть )
http://releases.qt-project.org/qt5.0/beta1/
>Несмотря на то, что основанные на QWidget классы чрезвычайно важны для существующих приложений, общая тенденция ведёт к тому, что все пользовательские интерфейсы должны быть реализованы на QML и Qt Quick.Это что, опять загоняют на QML+js?
Так это же к лучшему - абстракция
>Так это же к лучшему - абстракцияИ от чего же там абстрагируются?
От перекомпиляции под каждую платформу.
>От перекомпиляции под каждую платформу.Чем это лучше html5?
ты размер вебкита видел? А компилял? Он кстати на некоторых платформах аля встраиваемый линукс компилится только с помощью такой то матери.
> ты размер вебкита видел?Дык кутя теперь его сватает активно. Чем она лучше? :)
тем что у хтмл5 на жаваскрипте пишется вся логика приложения.
html5 говно. Задолбали уже из языка разметки текста пытаться сделать гибрида по логической разметки страницы.
Давно пора сделать мух и котлеты отдельно: отдельно что нить вроде qml, отдельно html (без наворотов типа div, js и т.д.)
> html5 гoвно. Задолбали уже из языка разметки текстаОно уже давно не язык разметки текста а скорее язык разметки сложных документов и пользовательских интерфейсов. Грань между которыми там просто отсутствует.
Может, всем? Синтаксисом, скоростью, возможностями, портируемостью, изначальной работой в OpenGL, полноценной сетью, доступом ко всем ресурсам устройства, работой как нативное приложение, а не интерпретатор?Это всё равно что спрашивать чем Т-90 лучше Т-34 - ведь оба танки!
Во-первых, с QML нужно чуть больше стараться, чтобы смешать логику приложения и UI, а такое разделение — очевидно, хорошо.Во-вторых, декларативный характер языка больше подходит описанию UI. Все ж писать гуйцы на C++ — это извращение. QML — большой шаг вперед в этом плане.
В-третьих, у интерпретатора QML чуть больше информации о том, что хочет сделать программист, поэтому некоторые вещи он может сделать оптимальнее. Ну, это как оптимизирующие компиляторы.
По сравнению с Lisp, Python и Ruby - JavaScript - жалкий калека. И если раньше связка C/Python/Qt была привлекательной, то теперь, когда JavaScript поставили во главу угла, она выглядит как архитектурный костыль. Почему они так носятся с этим JavaScript, неужели нельзя было продумать архитектуру так, чтобы упростить создание биндингов для скриптовых языков?
Я скорее про QML говорил, чем про JS.Олсо, все это куэмельное щастье все-таки ближе к Граалям типа FRP, нежели чем Qt/C++.
Да и не ставил никто JS во главу угла. Можно писать так же, как и раньше.
"We should expect that over time all UIs will be written in QML. JavaScript will become a first class citizen within the Qt community and we should expect that a lot of application logic and even entire applications will be written in JavaScript instead of C++."Судя по этой цитате они мечтают о том дне когда все программы под Qt будут писаться на JavaScript.
"While the QWidget based classes are extremely important for existing applications, we are, over time, going to move to a model where all UIs are being done in QML. Separating the QWidget based functionality into its own library is therefore a good measure to achieve a clean architecture in Qt 5 in the long term."
А судя по этой - QWidget будет вынесен в отдельную библиотеку, чтобы от него легче было избавиться, когда настанет светлое будущее QML.
> "We should expect that over time all UIs will be written in
> QML. JavaScript will become a first class citizen within the Qt
> community and we should expect that a lot of application logic
> and even entire applications will be written in JavaScript instead of
> C++."
> Судя по этой цитате они мечтают о том дне когда все программы
> под Qt будут писаться на JavaScript.Меня это тоже печалит. Особенно состояние QML сегодня, в Qt 4.8 — ИМХО неюзабельно.
Мне бы все-таки хотелось, чтобы C++ API тоже какое-то внимание уделялось.> "While the QWidget based classes are extremely important for existing applications, we
> are, over time, going to move to a model where all
> UIs are being done in QML. Separating the QWidget based functionality
> into its own library is therefore a good measure to achieve
> a clean architecture in Qt 5 in the long term."
> А судя по этой - QWidget будет вынесен в отдельную библиотеку, чтобы
> от него легче было избавиться, когда настанет светлое будущее QML.Оу, ну что ж вы так, заговоры везде видите. Просто императивные QWidget'ы не очень совместимы со scene graph'ом, нужным для нового QML, ЕМНИП.
> все программы под Qt будут писаться на JavaScriptНе программы! Интерфейсы - "all UIs will be written in QML". И это, в общем, правильное решение. А логику (расчёты, работу с файлами и БД и т.п.) делайте на C/C++.
> QWidget будет вынесен в отдельную библиотеку, чтобы от него легче было избавиться, когда настанет светлое будущее QML
Тоже логичное решение.
"we should expect that a lot of application logic and even entire applications will be written in JavaScript instead of C++"А здесь они пишут, что большая часть бизнес-логики и даже целые программы будут написаны на JavaScript. И далее по тексту - только критичные по времени выполнения куски будут переписываться на C++. Так что Qt превращается в среду разработки программ на JavaScript.
"Шарик! ТЫ балбес!" (с)QML это реализация GUI и не более, во всех пресс-релизах уже ДАВНО говорится, что С++ никто не выкидывает, его убирают только там где он не нужен!
Если у вашем "лидере сегмента рынка с дружественным коллективом" (с) GUI разрабатывают инженеры-программисты, то флаг Вам в руки и якорь ниже. В нормальных конторах этим занимаются специально выдрессированные люди, для которых использование C++ это попоболь, а вот что-то типа QML+JS самое оно. Да и проще людей на эту должность найти.
> По сравнению с Lisp, Python и Ruby - JavaScript - жалкий калека.
> И если раньше связка C/Python/Qt была привлекательной, то теперь, когда JavaScript
> поставили во главу угла, она выглядит как архитектурный костыль. Почему они
> так носятся с этим JavaScript, неужели нельзя было продумать архитектуру так,
> чтобы упростить создание биндингов для скриптовых языков?Только вот в сравнении с восьмицилиндровым двиглом от гугла как калеки выглядят интерпретароры всего вышеперечисленного.
>Только вот в сравнении с восьмицилиндровым двиглом от гугла как калеки выглядят интерпретароры всего вышеперечисленного.наглая ложь! для коммон лиспа есть превосходные многопроходные компиляторы в нативный код.
Вы компилятор от интерпретатора отличаете?
Если бы у разработчиков было желание компилировать всё в найтивный код, то они вряд ли бы использовали жаваскрипт.
Вы, по-моему, путаете причину со следствием. В данном случае глубоко фиолетово, интерпретируется или компилируется js-или-что-у-нас-там-для-рисования-интерфейса - лишь бы программы на нем имели удовлетворительные характеристики по потреблению ресурсов. Qt-проект так или иначе собирать придется, поскольку он не целиком на js.
А какой вообще был смысл тогда отказываться от клепания гуя на си++?Вы утверждаете, что разрабы вынесли гуй в скрипты для того чтоб использовать жаваскрипт, а не использовали жаваскрипт желая вынести гуй в скрипты?
> А какой вообще был смысл тогда отказываться от клепания гуя на си++?Потому что на js как язык проще для таких дел, чем c++
Вот, а теперь возвращаемся к моему паза-паза-пошлому посту.
Я скомпилирую этот код с 7и проходов
Слабак. Компиляторы фортрана делали по 42. Потому как ужать программу в 4кБ памяти вместе с данными, это надо уметь.
> Только вот в сравнении с восьмицилиндровым двиглом от гугла как калеки выглядят
> интерпретароры всего вышеперечисленного.Угу, особенно си на котором написан гугловский код и питон которым он собирается. Не, попытка троллинга неплохая, если б не хреновое знание матчасти :)
> Почему они так носятся с этим JavaScript, неужели нельзя было продумать архитектуру так, чтобы упростить создание биндингов для скриптовых языков?Не потому ли, что он патентно чистый?
Да? А ничего что даже название является торговой маркой Оракла?
>В-третьих, у интерпретатора QML чуть больше информации о том, что хочет сделать программист, поэтому некоторые вещи он может сделать оптимальнее. Ну, это как оптимизирующие компиляторы.И какие же оптимизации будет делать интерпретатор QML? :)
Будет — да вплоть до невычисления свойств-анимаций-етц для тех вещей, которые не нужны (например, не видны сейчас на сцене). Благо, декларативный характер описания вещей позволяет.Ну и не совсем то, но тоже в тему статья у них в блогах: http://labs.qt.nokia.com/2012/08/01/scene-graph-adaptation-l.../
> Будет — да вплоть до невычисления свойств-анимаций-етц для тех вещей, которые не
> нужны (например, не видны сейчас на сцене). Благо, декларативный характер описания
> вещей позволяет.Как же он будет определять на сцене эти объекты или нет, если их свойства всё же нужно вычислить для того чтобы понять видимы они или нет :)
Мы можем так же из Си положить на сцену объекты и у рендерера будет возможность не рисовать их(ну как в Clutter или e17 Evas).> Ну и не совсем то, но тоже в тему статья у них
> в блогах: http://labs.qt.nokia.com/2012/08/01/scene-graph-adaptation-l.../Правильно, совсем не то :)
Scene Graph и оптимизации связаные с ним никак не связаны с qml.
>> Будет — да вплоть до невычисления свойств-анимаций-етц для тех вещей, которые не
>> нужны (например, не видны сейчас на сцене). Благо, декларативный характер описания
>> вещей позволяет.
> Как же он будет определять на сцене эти объекты или нет, если
> их свойства всё же нужно вычислить для того чтобы понять видимы
> они или нет :)Все свойства не нужно вычислять. Например, если у вас есть какой-нибудь хитрый эллипс, то достаточно вычислить его этакий гарантированный bounding box по размеру большей из осей, а цвет, ориентацию и вообще любые свойства его дочерних элементов (если clip: true) вычислять не нужно будет.
> Мы можем так же из Си положить на сцену объекты и у
> рендерера будет возможность не рисовать их(ну как в Clutter или e17
> Evas).Признаться, Clutter/Evas не тыкал, но, возможно, выглядит все это страшно. Вон, как ниже писали про тот же куэмель.
И просто из интереса, как будет выглядеть связывание свойств?
> Все свойства не нужно вычислять. Например, если у вас есть какой-нибудь хитрый
> эллипс, то достаточно вычислить его этакий гарантированный bounding box по размеру
> большей из осей, а цвет, ориентацию и вообще любые свойства его
> дочерних элементов (если clip: true) вычислять не нужно будет.Ну в любом случае этим будет заниматься рендерер/итд кто использует Scene Graph. И все те же оптимизации доступны без всяких декларативных qml'ов.
Так что до сих пор не вижу преимуществ от qml'я, кроме как просто удобного языка для описания лэйаутов.> Признаться, Clutter/Evas не тыкал, но, возможно, выглядит все это страшно. Вон, как
> ниже писали про тот же куэмель.Выглядит практически так же как и разработка приложений на html5+js.
> Ну в любом случае этим будет заниматься рендерер/итд кто использует Scene Graph.
> И все те же оптимизации доступны без всяких декларативных qml'ов.
> Так что до сих пор не вижу преимуществ от qml'я, кроме как
> просто удобного языка для описания лэйаутов.Декларативно можно и на тех же плюсах писать, но зачем?
> Выглядит практически так же как и разработка приложений на html5+js.
ИМХО не стоит ставить HTML5 и QML в один ряд, таки разные технологии для разных вещей.
>Декларативно можно и на тех же плюсах писать, но зачем?Вообще не понимаю о чём вы если честно.
Это для вас будет слишком декларативно? :)
var a = document.createElement('div');
a.style.left = '10px';
a.style.top = '0px';
a.style.width = 'calc(100% - 2em)';
document.body.appendChild(a);>ИМХО не стоит ставить HTML5 и QML в один ряд, таки разные технологии для разных вещей.
Я говорю про создание приложений с Clutter/Evas, что это выглядит так же как сейчас создаются миллионы приложений с использованием html5+js :)
> Вообще не понимаю о чём вы если честно.
> Это для вас будет слишком декларативно? :)
> var a = document.createElement('div');
> a.style.left = '10px';
> a.style.top = '0px';
> a.style.width = 'calc(100% - 2em)';
> document.body.appendChild(a);Это для меня слишком императивно :(
> Я говорю про создание приложений с Clutter/Evas, что это выглядит так же
> как сейчас создаются миллионы приложений с использованием html5+js :)Я уже запутался, мы QML обсуждаем или HTML5 + JS? :)
> Это для меня слишком императивно :(Ну так вот всё тоже самое можно было делать без особых проблем на си без использования qml+js, если конечно позволяет апи. Но они решили что современный графический стэк будет доступен только из qml+js, из-за чего пошло много негодования. Еслиб был qml+js или C++, небыло бы никаких проблем, но теперь они просто поставили всех своих пользователей в положение, в котором им придётся мучаться с qml+убогим жаваскриптом, если они захотят использовать современные инструменты для разработки ui.
И суть оптимизаций в deferred рендере, вместо immediate и это никак не связано с декларативностью/императивностью языков.> Я уже запутался, мы QML обсуждаем или HTML5 + JS? :)
Вы там спросили о том как будет выглядеть разработка с использованием Clutter/Evas, я привёл пример на что это похоже.
> Ну так вот всё тоже самое можно было делать без особых проблем
> на си без использования qml+js, если конечно позволяет апи.QDomDocument тот же вполне позволяет. Будет выглядеть даже почти так же.
> Но они
> решили что современный графический стэк будет доступен только из qml+js, из-за
> чего пошло много негодования. Еслиб был qml+js или C++, небыло бы
> никаких проблем, но теперь они просто поставили всех своих пользователей в
> положение, в котором им придётся мучаться с qml+убогим жаваскриптом, если они
> захотят использовать современные инструменты для разработки ui.Вообще, конечно, и мне было бы интересно почитать, что такое потребовало QML. Они говорят, что императивный QPainter не позволяет строить вещи типа сцен-графа. Почему то же нельзя сделать на плюсах — хороший вопрос.
> И суть оптимизаций в deferred рендере, вместо immediate и это никак не
> связано с декларативностью/императивностью языков.Вы бы еще сказали, что суть оптимизаций в определении мертвых участков кода, и это никак не связано с ленивостью/«функциональностью» языков.
>> Я уже запутался, мы QML обсуждаем или HTML5 + JS? :)
> Вы там спросили о том как будет выглядеть разработка с использованием Clutter/Evas,
> я привёл пример на что это похоже.Я скорее спрашивал про примеры кода, ибо уверен, что достаточно сложные вещи будут выглядеть ужасно на императивных вещах.
А хтмл сюда, впрочем, тоже не нужно примешивать ИМХО. Точно так же не нужно.
> Вы бы еще сказали, что суть оптимизаций в определении мертвых участков кода,
> и это никак не связано с ленивостью/«функциональностью» языков.Вы вообще как читали статьи qt'шников, раз уж у вас все познания только из их источников? Тк когда я читал, у них всё было грамотно написано, а вы пишете про какую-то чушь :)
Все оптимизации строятся на том что рендерер видит сразу всю сцену и может производить различные оптимизации, а как уж там мы наполняли эту сцену - тут похер, можем через декларативный qml, либо из императивного си++ еслиб они предоставили какой-нибудь нормальный апи для этого.
И то что мы наполнили сцену, используя императивный апи, совсем не значит что мы не можем повесить колбэк на какое-то из свойств объекта и динамически его вычислять только при надобности, если вдруг рендерер захочет нарисовать этот объект (видимо это до вас не доходит).
И никаких уникальных оптимизаций интерпретатор qml не выполняет.>А хтмл сюда, впрочем, тоже не нужно примешивать ИМХО. Точно так же не нужно.
Так бы и сказали, что никогда не писали веб-приложений на html+js. Тк люди, которые имели опыт с этими технологиями отлично представляют плюсы и минусы различных подходов вроде смеси декларативного+императивного(AngularJs, Ember, Knockout итд), либо просто императивного(большинство других библиотек).
>[оверквотинг удален]
> было грамотно написано, а вы пишете про какую-то чушь :)
> Все оптимизации строятся на том что рендерер видит сразу всю сцену и
> может производить различные оптимизации, а как уж там мы наполняли эту
> сцену - тут похер, можем через декларативный qml, либо из императивного
> си++ еслиб они предоставили какой-нибудь нормальный апи для этого.
> И то что мы наполнили сцену, используя императивный апи, совсем не значит
> что мы не можем повесить колбэк на какое-то из свойств объекта
> и динамически его вычислять только при надобности, если вдруг рендерер захочет
> нарисовать этот объект (видимо это до вас не доходит).
> И никаких уникальных оптимизаций интерпретатор qml не выполняет.Я, вероятно, недостаточно хорошо выразился. Очевидно же, что декларативный подход оставляет больше свободы для, гм, интерпретации кода, нежели чем императивный. В декларативном случае проще соблюдать инварианты при преобразованиях (и оптимизациях в том числе) — в императивном случае все равно придется строить и поддерживать этакую картину состояния системы, убеждаясь, что после оптимизаций код все равно обеспечивает изоморфное преобразование из одного состояния в другое. Это весьма затрудняет построение оптимизатора.
А рендерер всю сцену уже со времен QGraphicsView видит, тащем-та.
Еще раз, декларативно можно и на плюсах писать, но зачем? Все равно вы в конечном счете придете к какому-то (embedded) domain-specific language, так почему бы сразу не писать на нем? :)
>А рендерер всю сцену уже со времен QGraphicsView видит, тащем-та.Вы вообще не понимаете зачем создавались разные вещи в Qt :) QGraphicsView решал совершенно другие проблемы, этот класс был больше для удобства разработчиков, которым нужно быстренько создать "сцену" для определения куда тыкают мышкой итд. И в отличие от SceneGraph'а в Qt5, чайлды в qgv использовали тот же qpainter для отрисовки из-за чего невозможно сделать множество оптимизаций, которые производит рендерер в qt5.
>Еще раз, декларативно можно и на плюсах писать, но зачем? Все равно вы в конечном счете придете к какому-то (embedded) domain-specific language, так почему бы сразу не писать на нем? :)
Ещё раз повторю, тот пример выше на JavaScript'е - это для вас что декларативно? Тысячи игрушек, в движках которых используются такие же оптимизации написаны на каких-то декларативных qml'ях? e17 Evas работает только используя какой-то декларативный язык?
Зачем вы продолжаете нести чушь про какой-то embedded dsl?
> Вы вообще не понимаете зачем создавались разные вещи в Qt :) QGraphicsView
> решал совершенно другие проблемы, этот класс был больше для удобства разработчиков,
> которым нужно быстренько создать "сцену" для определения куда тыкают мышкой итд.Едва ли. Определять мышкой можно и в старом-добром QWidget API. Вся эта хрень со сценами создавалась именно как более high-perf-вещи для рисования здоровенных сцен.
По-моему, это у вас какое-то непонятное непонимание :)
> И в отличие от SceneGraph'а в Qt5, чайлды в qgv использовали
> тот же qpainter для отрисовки из-за чего невозможно сделать множество оптимизаций,
> которые производит рендерер в qt5.Кажется, я не так давно говорил то же самое.
>>Еще раз, декларативно можно и на плюсах писать, но зачем? Все равно вы в конечном счете придете к какому-то (embedded) domain-specific language, так почему бы сразу не писать на нем? :)
> Ещё раз повторю, тот пример выше на JavaScript'е - это для вас
> что декларативно?Нет.
> Тысячи игрушек, в движках которых используются такие же оптимизации
> написаны на каких-то декларативных qml'ях?И что доказывает существование, кроме моего тезиса, что и на плюсах/whatever можно писать декларативно?
> Зачем вы продолжаете нести чушь про какой-то embedded dsl?
Если вы не знаете предметную область, то лучшей стратегией будет ознакомиться с ней, нежели чем называть непонятные слова чушью.
>Едва ли. Определять мышкой можно и в старом-добром QWidget API. Вся эта хрень со сценами создавалась именно как более high-perf-вещи для рисования здоровенных сцен.И что вы там будете определять в QWidget API? Координаты места куда произошёл клик? :)
qgv - это аналог того что предоставляет flash player, достаточно удобная вещь для своих целей, создавалась для удобства разработчиков, а не для увеличения производительности.>Кажется, я не так давно говорил то же самое
Ну так и зачем тогда вообще говорите про qgv, если понимаете что чайлды там используют qpainter и из-за этого невозможно получить профит на современном железе?
>И что доказывает существование, кроме моего тезиса, что и на плюсах/whatever можно писать декларативно?
я вам выше привёл пример того как мы заполняем сцену(html document) на джаваскрипте, вы сказали что это не декларативно, а теперь опять продолжаете вещать о том что на плюсах/whatever можно писать декларативно :) Вы уже определитесь.
>Если вы не знаете предметную область, то лучшей стратегией будет ознакомиться с ней, нежели чем называть непонятные слова чушью.
Вы недавно прочитали про декларативное программирование, нашли в нём какие-то ключевые моменты и теперь вам кажется что это one-true-way для работы с определённым кругом задач? Почитайте вообще про парадигмы программирования для начала прежде чем продолжать нести чушь: Programming Paradigms for Dummies: What Every Programmer Should Know http://www.info.ucl.ac.be/~pvr/VanRoyChapter.pdf
p.s. И до сих пор не услышал ни про какую оптимизацию, которую производит интерпретатор qml :)
> Вообще не понимаю о чём вы если честно.
> Это для вас будет слишком декларативно? :)
> var a = document.createElement('div');
> a.style.left = '10px';
> a.style.top = '0px';
> a.style.width = 'calc(100% - 2em)';
> document.body.appendChild(a);Вообще-то это очень хреново. Потому-что дает возможность перемешивать представление и логику в одну большую макаронину. Например:
var a = document.createElement('div');
a.style.left = '10px';
a.style.top = '0px';
<решение квадратичного уравнения, несколько строк кода>;
a.style.width = 'calc(100% - 2em)';
<еще вычислили среднюю зарплату по отделу, еще 20 строк кода>;
document.body.appendChild(a);Поди потом, разберись, что пьяные программист с дезигнером имели ввиду.
А особенно это хреново для визуальных средств разработки. Вместо какого-то файла описания формы/контролов с известной средствам разработки схемой построения такого файла, эти средства заняты тем что парсят исходный код и пытаются по нему воспроизвести внешний вид формы (ищут конструкторы контролов и всяческих лайаутов, присваивания свойствам объектов каких-то значений), вместо того чтобы просто распарсить какой-то тектовый (или xml-ный) файл сцены/формы и по нему построить визуальное представление. А еще в этом дурацком подходе раздражают комментарии к таким длинным макаронным функциям (в которых средствами разработки создаются контролы) - "Этот код был сгенерирован автоматически и потому его руками не трожь! Все твои изменения будут перетерты при следующем редактировании". Чисто защита на честном слове.
т.е. куда лучше и удобнее вынести такое описание в отдельный файл:... root ... encoding ...
<document name="aaa">
<style ...>
<left>10px</left>
<top>...</top>
<width>...</width>
...
</style>
</document>
...Причем не обязательно xml, если он вам не нравится, придумать другой формат описания свойств, например, а-ля делфи с его файлами dfm, где в текстовом виде описана компоновка формы со всеми контролами и свойствами.
т.е. в данном случае ты уже бы никакую фигню не всунул между строками кода создания контролов. А уж для всяческих средств - построителей интерфесов это вообще песня - не надо парсить исходный код - тупо разобрал файл в памяти в дерево объектов и отобразил. Плюс появляется возможность проверить такой файл на валидность - схема описания и возможных свойств объектов где-то же описана. А этот файл впоследствии всунули бы в ресурсы и обрабатывали его в конструкторе при создании объекта-формы (-документа). Плюс даже не в текстовом виде, а в каком-то компильнутом бинарном виде (если так хочется) или даже в виде куска макаронного программного кода, которого ты не видишь, который не захламляет твой исходный код (т.е. такой код создавался бы по файлу свойств в момент сборки приложения и его исходный код ты вообще бы не видел в своем проекте)
Как они уже со своим яваскриптом..., а ведь такой чудесный фреймворк был для gui. Придется переходить обратно на gtk.
Просто прекрасно
>Как они уже со своим яваскриптом..., а ведь такой чудесный фреймворк был для gui. Придется переходить обратно на gtk.Да, это проблема. Всё идёт к тому, что плюсы останутся только для написания расширений под Quick. Непонятно только, чем это лучше обычного HTML-броузера, в котором имеются точно такие же возможности. По крайней мере HTML, как-никак, стандартизован и есть возможность выбрать/написать альтернативную реализацию.
Кто-то говорил ещё, что QML удобен также для написания гуя в программах на C++. Но это то ещё "удовольствие". Во-первых, с собой надо тащить V8, а во-вторых взаимодействия с элементами формы посредством вложенных findChild не назовёщь удобным. Вот пример из документации:
QObject *rect = object->findChild<QObject*>("rect");
if (rect)
rect->setProperty("color", "red");
> QObject *rect = object->findChild<QObject*>("rect");
> if (rect)
> rect->setProperty("color", "red");1. Где тут QML?
2. Этот способ для того случая, когда остальные недоступны.
>> QObject *rect = object->findChild<QObject*>("rect");
>> if (rect)
>> rect->setProperty("color", "red");
> 1. Где тут QML?
> 2. Этот способ для того случая, когда остальные недоступны.Речь про взаимодействие между QML и С++. Читай документацию, короче.
Та да, я вобще не понимаю этих людей - и в Tizen, и в Qt, и везде они пытаются эту жуть засунуть. Сколько не пишу на JS - не могу привыкнуть. Его кажись какой-то наркоман Павлик придумал, ибо чтобы получать удовольствие от программирования на js нужно напиться, забыться, а когда вспомнишь как тебя зовут - закинуться какими-нибудь колёсами. Причём и название понтовое как водится придумали "аспектно ориентированное программирование" - так хочется этим ребятам все их аспекты со всего размаху в ж... засунуть! Всех в сад, оставить ASM и C для контроллеров и C++ для компов и прочих мощных железяк, а всех остальных велосипедистов в одной яме закопать!
вот только не надо про всех остальных за всех остальных решать.
для контроллеров кстати и так всё чудесно - всё как ты хотел: асм и си.
и да, твой список неполон. перл где? шелл где? :)
> вот только не надо про всех остальных за всех остальных решать.
> для контроллеров кстати и так всё чудесно - всё как ты хотел:
> асм и си.
> и да, твой список неполон. перл где? шелл где? :)Да, про шелл 100% согласен, првтыкал. Оставить что-то годное, но одно. А вобще то о чём я писал не сбудется никогда :-)
> Да, про шелл 100% согласен, првтыкал. Оставить что-то годное, но одно. А
> вобще то о чём я писал не сбудется никогда :-)и не надо :) пусть будет, как будет. "Одна ОС и та от МС" уже проходили, "Один мир, одно государство, один фюрер" тоже :)
"...поддерживает в полной мере средства для создания Qt-программ на языке C++..."как звучит то, а? такими темпами в 5.5 возьмут да удалят "...давно устаревшие средства создания Qt-программ на языке C++..."
>[оверквотинг удален]
> Ключевые изменения Qt 5:
> - Модульная структура (http://www.opennet.me/opennews/art.shtml?num=28425) репозитория.
> QPA значительно упрощает перенос Qt на новые оконные системы и устройства,
> так как он изначально оперирует более абстрактными категориями, фундаментально отличаясь
> от ранее используемых средств интеграции с оконными системами.
> - Изменение архитектуры графического стека и увеличение производительности графических
> операций. В качестве центрального элемента новой архитектуры для Qt Quick выступает
> QML Scenegraph, работающий поверх OpenGL.
> Обеспечивающие выполнение JavaScript классы (QJSEngine и QJSValue) теперь
> базируются на JavaScript-движке V8XUL/Firefox 2.0. А хотелось бы Qcl/Qt.
> Новость: http://www.opennet.me/opennews/art.shtml?num=34701
> Переработанная реализация Qt Quick 2, которая разделена на отдельные модули, связанные с графической частью и с компонентами поддержки языков QML и JavaScript.А из этого случайно не следует, что можно будет (человеческими усилиями) выпилить JavaScript? ...А заменить его BlaBlaScript'ом?
Зачем менять шило на мыло?
> А из этого случайно не следует, что можно будет (человеческими усилиями) выпилить
> JavaScript? ...А заменить его BlaBlaScript'ом?Но зачем, или Qt пугает вас своей скоростью и вы хотите что б оно начало тормозить?
Тут два вопроса. Совершенно разные. (Просто не хотел запутывать)1. Я хочу использовать QML/C++, без присутствия интерпретатора JavaScript.
2. Мечтаю заменить JavaScript -> Ruby :)
1. Хотеть можете. Но это примерно как я хочу использовать Qt но без присутствия QtNetwork. Ну не используйте скрипты для интерфейса, вас же не заставляют, но при чём тут интерпритатор? У вас аллергия на интерпретаторы жаваскрипта?
2. Та же аналогия: я мечтаю заменить QtNetwork на GNet. Плюсов руби дать не может, а вот скорость - очевидный минус.Мне очень интересно, а зачем вам это?
Разумеется, just for fun. Но это надо брать код и разбираться... Я просто хочу еще понять, как туда вшит JavaScript? Как что-то отдельное? Или в QtWebKit? В QtQml?P.S. Выигрыша никакого. Ну если не вспоминать про всякого рода биндинги... А вот если вместо JavaScript представить нечто абстрактное... Типа LLVM, условно говоря... Мне кажется, это интересная (на уровне funтазии рассуждаю, опять же, но!) модель:
Qt/C++ (компилируемое) + QML (декларативное) + *Script (интерпретируемое)
А сейчас этот JavaScript к чему-то пришит... Интересно же воплощение этой модели, где каждая часть абстрактна (в смысле абстрактного класса), а реализацию можно заменять...
> в то время как применение C++ позиционируется для реализации критичных ко времени выполнения или излишне сложных частей программы,пщщщ, ВСЕ как писАл на плюсах так и буду! А там С++11, уумм няшка. Играйся там с этими дексракативными интерфейсами. На десингере запилил, uic window.ui > window.h и все. А то там ещё кучу костылей для взамиодействия этих ваших жабосриптов с с++ лепи. Трата памяти и производительности в пустую.
Что-то Qt всё больше становится завязанным на C++/JavaScript и менее привлекательным для использования с другими языками программирования. Похоже, зря я сделал на него ставку в прошлом - нужно было изучать Яву и не забивать себе голову.
Ява значит боле привлекательна для использования с другими языками программирования? Оракл уже четыре месяца не исправляет критические уязвимости.
>Оракл уже четыре месяца не исправляет критические уязвимости.Ораклопроблемы. Есть же реализация от IBM.
Нет но между двумя монолитными кусками C++/JS/Qt и Java - я склоняюсь к Java. Под JVM существуют реализации таких языков программирования, как Python, Ruby, Erlang, Lisp (Clojure) и я подозреваю, что организовать их совместную работу друг с другом и с тоннами кода под JVM будет гораздо легче, чем привинтить их к Qt. Персонально - мне не нравится C++, мне не нравится идея совместить абстрактные вещи типа шаблонов и ООП с прямой работой с памятью, и особенно мне не нравятся ошибки которые при этом возникают и безумные отчёты дебагера о них.
Бред сумасшедшего безумца!
>Ява значит боле привлекательна для использования с другими языками программирования? Оракл уже четыре месяца не исправляет критические уязвимости.Смотря какие уязвимости. А то я вот серверов на Qt что-то не встречал.
Qt позиционирует как десктопный тулкит.
>Qt позиционирует как десктопный тулкит.Ну значит ява в десктопном применение тоже без дыр.
Эх, а про WebKit2, с разделением на процессы из коробки, ничего. А ведь вроде как обещали к бетке Qt 5.Да и, похоже, к WK2 доступ будет только из QML, а хотелось бы и из C++ доступ получить без всяких извращений.
вы не поверите, но я только вчера ночной билд на винду закачал..
В линуксе работает на удивление хорошо, в винде не умеет разделение на процессы.
Интересно мне, у кого-то запускаются проги собранные с Qt5 на блобах? В частности с нвидиивским. У меня запускаются только с открытыми дровами, с закрытыми:XIO: fatal IO error 11 (Ресурс временно недоступен) on X server ":0"
after 15 requests (15 known processed) with 0 events remaining.
Ошибка сегментирования0_о
Запускаются. Собираю Qt5 сам из гиториуса.
> Запускаются. Собираю Qt5 сам из гиториуса.Забыл уточнить
sh NVIDIA-Linux-x86_64-304.37.run --opengl-headers
При этом используются и заголовки поставляемые вместе с драйвером.
Включил в пкгбилд хидеры из блоба, пересобрал qt5-base-git - не запускаются (
Я изретка собираю Qt5 дабы потестить и пощупать эти ихние "иновации". Вот сейчас собрал 0 не запукается... Попробую установить блоб с хидерами.
А все, понял в чем прикол. У меня Qt был собран на OpenGL ES2, блобы ES не умеют же. Собирал до этого для вяленого...
Скачал qt-linux-opensource-5.0.0-beta1-x86_64-ubuntu1204-offline.run и установил - такой пакет полностью соответствует моей ОС и разрядности (64 бит). Подключил в Qt Creator 2.5.2, создал новый проект с GUI (не QML, просто виджеты, в pro файле есть "greaterThan(QT_MAJOR_VERSION, 4): QT += widgets"). Скомпилировалось!При запуске вот чо:
Failed to load platform plugin "xcb". Available platforms are:
linuxfb
minimal
xcbПрограмма неожиданно завершилась.
Что делать? ЧЯДНТ?
Не найден plugin "xcb", дайте путь к библиотекам Qt в LD_LIBRARY_PATH и если и это не поможет, то QT_PLUGIN_PATH к директории plugins
> Не найден plugin "xcb", дайте путь к библиотекам Qt в LD_LIBRARY_PATH и
> если и это не поможет, то QT_PLUGIN_PATH к директории pluginsя прописал и в креаторе, и просто в консоли пробовал - не находит, хотя явно видно libxcb.so лежит
Такими темпами в Qt 6.0 останется только javascript, который будет выполняться на "облачном" сервере Корпорации Добра Google (tm), причём чтобы запустить "приложение" нужно будет залогинитьсяЗато кросплатформенно! Безопасно! Доступно! Интырпрайз!
> Зато кросплатформенно! Безопасно! Доступно! Интырпрайз!отставить истерику, матрос
это самое страшное если они откажутся от QWidgets в Qt 6.0, хорошо что выделили в отдельную библиотеку - это минимизирует шансы того что выкинут ибо теперь оно им не так мешает, а сообщество сможет поддерживать чтобы оно и дальше работало впредь
Сначала KDE превратился в монстра, затем Gnome... Теперь вот Qt. Везде представители нового поколения, которые обожают рушить парадигмы, которые режут по живому.
правильно я понимаю что Qt сначала был монолитным куском всем не нравившимся, его начали распиливать. И когда уже распили на отдельные части, по пути выкинув что не нужно, оказалось что внутри сидит другой монолитный кусок - вебкит?
Нет. Кому это всем? Тулкитофобом из противоположного лагеря? Их ненависть сначала основывалась на том, что у Qt была неправильная лицензия, потом на том, что это C++, комбайн, не гтк. Если вы не программист, то какая вам разница на чем написана программа?
Про вовсёмпутинвиноват ещё не написал. Что там в тексте то было понял? Там про тулкитофобию вааще ни слова.
Меня зацепила откровенная ложь, а твое непонимание из чего состоит Qt меня не интересует. Аналитеги сначала наслушаются на форумах, потом неправильно пойму, а потом слухи и домыслы пускают.
А меня твоё непонимание прочитать пару строк текста очень интересует - в гельминтологических целях. Про тулкитофобию оказалось это твои домыслы. Из чего состоит кутя и моё непонимание этого тебя не интересует. Зачем же ты отвечал на вопрос тебе лично не заданный? Какой бугурт заставил тебя влезть и попытаться потешить своё ЧСВ? Заметим, неудачно потешить.
А мысли по поводу куда двигается кутя собираю из текстов куте-лабс и примерно вот таких заметок http://www.open-life.org/blog/1880.html . Но ты можешь попробовать подпустить ещё слухов и домыслов кто что не понимает, хотя это тебя "совершенно не интересует".
Я тете уже объяснил, но ты с первого раза не понял. Еще раз. Я ответил на твою наглую ложь:
>...Qt сначала был монолитным куском всем не нравившимся...
>...всем не нравившимся...
Бугурт евривеа? Тете каких-то видишь. Главное дыши поглубже. А то вишь целых три дня скакал что бы сказать как я тебе безразличен.
> Если вы не программист, то какая вам разница на чем написана программа?Из этого часто вытекают некоторые свойства, важные и для непрограммистов. Скорость работы, системные требования (рантаймы/зависимости), "красивости" интерфейса.
А что на сайте Digia написано:>Если вы уже являетесь держателем лицензии Qt Commercial, вы можете скачать бета-версию 5.0 с портала Qt Commercial Customer Portal.
>Если у Вас еще нет лицензии, пожалуйста, загрузите бесплатную 30-дневную триальную версию с нашего сайта или обратитесь к нашему менеджеру по продажам за дополнительной информацией о лицензировании Qt.Ето они о чем
>Qt CommercialКоммерческая. Всё.