Мысли по поводу Qt 5

Автор оригинала: Lars Knoll [Qt Labs]
  • Перевод
Qt 4.0 была выпущена в июне 2005 года, почти шесть лет назад. Многое изменилось в индустрии программного обеспечения за эти годы. Тогда разработка приложений шла в основном на настольных системах, сейчас же мобильные устройства, подключенные к сети, становятся все более популярными. Технология пользовательского интерфейса перешла от статических виджетов к плавным сенсорным. Начиная с Qt 4.0, мы выпустили семь минорных версий Qt, следуя потребностям разработчиков и пользователей, например, разработав Qt Quick. С растущей пользовательской базой Qt, растёт потребность во встроенных, мобильных приложениях и UI-разработчиках.

Кроме того, в будущем, чтобы быть ведущим фреймворком для разработчиков в нескольких отраслях, Qt необходимо непрерывно обновляться и развиваться. Qt 4 был эволюцией, поэтому я задумался о том, как могут выглядеть следующие версии Qt с технической точки зрения. Последние годы мы работали над созданием основы для следующей мажорной версии. Я вижу в ней Qt Quick, QML Scenegraph и проект Lighhouse в сочетании с усилением акцента на Qt Webkit как фундамент, который мы планируем использовать для перехода к новому мажорному релизу Qt.

Учитывая, что Qt управляется открыто, я хотел бы поделиться своими размышлениями с сообществом Qt, чтобы начать дискуссии о технической архитектуре Qt 5.


Цели следующей мажорной версии Qt (Qt 5)

  • Улучшить использование GPU, позволяя создавать плавную (и ускоренную) графику даже при ограниченных ресурсах;
  • Сделать создание современных приложений и пользовательских интерфейсов проще и быстрее (с использованием QML и JavaScript);
  • Сделать приложения, подключенные к Сети, мощнее и лучше, то есть дать возможность легко встраивать веб-контент и веб-сервисы в любое приложение Qt.
  • Уменьшить сложность и объем кода, необходимого для поддержания и реализации портов.
Qt 4.7 содержит немного унаследованного кода, что позволяет нам сделать Qt лучше для создания приложений и пользовательских интерфейсов нового поколения. Хотя большая часть все еще имеет очень важное значение для наших разработчиков, но некоторые части тормозят последующее развитие.

Сделать несложным переход с Qt 4 на Qt 5


В Qt 5 мы планируем сделать некоторые изменения в API и оставить позади ограничения из прошлого, чтобы было лучше в будущем. Для тех из вас, кто был с нами при переходе Qt 3 на Qt 4, мы не планируем повторять подобные трудности перехода в Qt 5. Мы считаем, что можем сохранить совместимость в большинстве случаев, но потери бинарной совместимости не избежать. Мы сделаем все, чтобы избежать нарушения каких-либо основ и сделать переход с Qt 4 на Qt 5 очень простым для большинства приложений.

Qt 5 будет сосредоточено на небольшом наборе операционных систем/платформ (т.е. платформ Wayland и X11 на Linux, Mac и Windows). Общее число платформ будет зависеть от усилий открытого сообщества, вложенных в Qt. Другие операционные системы, в настоящее время поддерживаемые Qt 4 (особенно коммерческие системы UNIX), не будут в центре внимания для Nokia. Целью проекта Qt 5 является предоставление наилучшей функциональности на каждой платформе, что означает, что Qt начнёт предлагать более дифференцированные возможности на разных ОС, в то же время предлагая эффективное повторное использование большей части кода на разных платформах.

Открытая разработка вместе с вами при сильной поддержке Nokia


Другим важным изменением в Qt 5 будет модель разработки. Qt 4 был разработан в основном в Trolltech и Nokia, затем опубликован для сообщества разработчиков. Qt 5 мы планируем развивать открыто, как проект с изначально открытым исходным кодом. Не будет никаких различий между разработчиками, работающими в Nokia и другими участниками.

Если вы или ваша компания хотите принять участие в разработке Qt 5, пожалуйста, присоединяйтесь к саммиту разработчиков Qt в Берлине с 16 по 18 июня. Это основное место, где мы хотели бы обсудить вместе с вами планы и идеи для Qt 5.0 и 5.1. Некоторые из нас также будут на саммите разработчиков Ubuntu на этой неделе и конференции MeeGo в конце этого месяца.

Обзор


Qt 5 должна быть основой для нового способа разработки приложений. Пока вся мощность нативности Qt в использовании C++, предлагается сфокусироваться на переходе к модели, где C++ используется в основном для реализации модульного бэкэнда функциональности для Qt Quick.

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

Хотя традиционные Qt/C++ приложения и будут продолжать работать с Qt 5, но произойдут некоторые фундаментальные изменения в том, КАК приложения могут быть и будут написаны.

Следует ожидать, что с течением времени все интерфейсы будут написаны на QML. JavaScript основным в сообществе Qt, и мы должны ожидать, что большая часть логики приложений и даже целые приложения будут написаны на JavaScript, а не C++. Ожидается, что многие разработчики приложений на уже сейчас начнут с QML и JavaScript, и будут реализовывать функции на C++ лишь тогда, когда это требуется. В некоторых случаях, вся мощь C++ API, предлагаемая Qt, может быть использована для реализации критичных по времени и сложных по функциональности приложений.

Хотя мы и предлагаем поддержку основанной на QWidget модели программирования и набор API для совместимости, в долгосрочной перспективе мы также видим QML как будущее пользовательских интерфейсов на рабочем столе. Решением здесь является основанные на QML наборы компонентов, которые интегрируются с нативными API стилизации на настольных платформах.

Четыре больших архитектурных изменения

  1. Реструктуризация нашего графического стека
    Мы поместим Qt Quick и QML Scenegraph в центр нашей новой графической архитектуры. QPainter по-прежнему будет доступен и очень полезен для многих вещей, но он не будет использоваться для основного интерфейса пользователя. Qt потребует OpenGL (ES) 2.0 для работы. QWidgets будет в иерархии на вершине графа сцен (а не граф сцен на вершине QWidgets, как это сейчас делается в Qt 4).
  2. Все порты Qt будут основаны на Lighthouse
    Проект Lighthouse был начат с целью обеспечения лучшего способа абстрактной интеграции оконных систем, чем мы в настоящее время используемся. Он в настоящее время достигает зрелости в Qt 4.8, и мы намерены использовать Lighthouse для всех портов Qt в Qt 5.0.
  3. Модульная структура репозитория
    Много работы было сделано за последние недели, и вы можете увидеть результаты в новых модульных репозиториях Qt. Модуляризация позволит облегчить и ускорить совместную разработку Qt.
  4. Отделение всех связанных с QWidget функций в отдельную библиотеку
    Пока что классы, основанные на QWidget, чрезвычайно важны для существующих приложений, но с течением времени мы будем приближаться к модели, где все интерфейсы создаются в QML. Выделение функциональности, связанной с QWidget, свою отдельную библиотеку — это хорошая мера для достижения чистой архитектуры Qt 5 в долгосрочной перспективе.
Как вы видели из предыдущих постов, первые три пункта были разработаны в течение достаточно долгого времени, и мы уже начинаем работу над последним. Ожидается, что большая часть этих изменений будет сделана до августа.

Qt Components и Qt Mobility теперь станут неотъемлемой частью платформы Qt, а не модулями со специальным статусом.

Бета-версии доступны к концу 2011 года. Финальный релиз в 2012 году


То, что мы не хотим слишком изменить основы Qt и тот факт, что мы хотим сделать переход существующих приложений на Qt 5 простым, заставляют нас быть осторожными с количеством изменений и существующей базой кода. Большую часть изменений мы уже вам предложили, а также мы начали работы над реструктуризацией нашей кодовой базы в новую модульную структуру, где каждая динамическая библиотека находится в своем собственном репозитории. Мы считаем, что мы должны удалить некоторые очень редко используемые API, которые сохранены для совместимости, но останавливают последующее развитие. Мы также считаем, что бета-версии будут доступны к концу года и окончательный релиз Qt 5.0 будет выпущен в 2012 году.

На прошлой неделе был выпущен Qt SDK с обновлениями, которые планируется использовать в предстоящем году для целевых устройств с Nokia Symbian и MeeGo. Qt 5.0 сосредоточена вокруг следующего поколения приложений и пользовательских интерфейсов, но серьёзных сложностей с переходом на эту версию возникнуть не должно.

Помогите нам ускорить разработку


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

Вы можете следить за нашей работой в хранилищах Qt. Мы намерены поддерживать master-ветку пригодной для использования в любое время, по крайней мере на Linux с Wayland и X11 (плагин xcb lighthouse).

Возможно, что некоторые функции не будут в полной мере доступны в Qt 5.0 и появятся лишь с течением времени в последующих версиях, но надеемся, что существенной регрессии функциональности для Qt 4.8 не будет (да, мы намерены выпустить еще одну промежуточную версию в серии Qt 4.x в течение следующих нескольких месяцев!). При разработке Qt 5 мы должны сделать все от нас зависящее, чтобы сохранить совместимость с Qt 4, так чтобы портирование приложений на Qt 5 было как можно более простым. Так что, если вы хотите помочь или поучаствовать в разработке Qt 5, мы ждем вас на саммите разработчиков Qt в Берлине в июне этого года.
Поделиться публикацией

Комментарии 43

    +3
    Обнадеживает.

    C QML не работал, но видимо что-то типа WPF XAML, с декларативной разметкой и аппаратным ускорением.
      +1
      Угу. Плюс QML — это валидный код на Javascript, и кроме разметки можно в этих же файлах прописывать логику работы.
      +4
      Интересно, начнется ли KDE 5 с выходом Qt 5…
        +1
        Судя по обозначенным направлениям, KDE так или иначе придётся перекладывать на QML.
          +1
          Да ладно вам, из тенденций в сторону QML я заметил только желание переписать все плазмоиды на QML. А в KDE есть еще кое-что помимо плазмоидов :)
          +4
          Не менее интересный вопрос — как принятие 0x повлияет на новые версии Qt.
            +3
            В коде Qt есть макросы для использования некоторых фич из нового стандарта, если компилятор их поддерживает
              +2
              Можно привести пример этих макросов и указать где можно посмотреть такой код в qt?
                +5
                Например:
                # define Q_COMPILER_RVALUE_REFS
                # define Q_COMPILER_INITIALIZER_LISTS
                # define Q_COMPILER_AUTO_TYPE
                # define Q_COMPILER_LAMBDA

                вот отсюда
            +1
            KDE4 ещё далёк от совершенства (чёрт побери, Akonadi полноценно начали использовать только с 4.6!), так что о KDE5 никто ещё не думает.
            С другой стороны, KDE 4.7.4 (последний багфикс-релиз в новой ветке) планируется аж на начало декабря (!), когда уже, судя по статье, планируются беты Qt 5; а судя по тенденциям, KDE 4.8 будет. Так что скорее всего дело будет как с KDE 4.0, которая базировалась толи на Qt 4.2, толи на 4.3… :)
              +1
              > о KDE5 никто ещё не думает.

              Вы явно не читаете KDE Planet: aseigo.blogspot.com/2011/05/qt5-kde5.html

              Вкратце с опеннета:
              Релиз KDE 5 будет иметь эволюционный характер, напоминая по своей сути переход от KDE 2 к KDE 3. По мнению Аарона, в Qt 5 ожидаются слишком большие изменения, которые не позволят без нарушения совместимости интегрировать в KDE 4 новые технологии Qt. Тем не менее, работа по переводу приложений на использование технологии декларативного описания интерфейса Qt Quick уже достаточно давно ведется в KDE. В частности, на базе подобных технологий уже развиваются проекты libplasma2 и Plasma Active.

              Положительным моментом также является то, что основная часть платформы KDE базируется на собственных библиотеках и runtime-компонентах, которые не потребуется переписывать, как было сделано в случае подготовки KDE 4. Несмотря на то, что в процессе создания KDE 5 не придется проводить глобальный реинжиниринг архитектуры проекта, у разработчиков появится шанс еще раз проанализировать и оптимизировать связь всех компонентов платформы. Из подсистем, которые потребуют значительной переработки, отмечаются библиотеки для формирования пользовательского интерфейса (libkdeui) и KIO. Более подробно вопросы перехода KDE на Qt 5 будут рассмотрены на ближайшем саммите разработчиков проекта.
                0
                Забавно. KDE Planet я читаю, и этот пост Аарон опубликовал уже после моего сообщения (буквально через час, если верить таймстампу в моём RSS-ридере) :)
                Ну а до этого про KDE 5 упоминался только вскользь — да и то, только в виде «может быть, когда-нибудь, в следующей жизни, это запилим, и это будет примерно в KDE5».

                Ну, и я считаю, что это набор мыслей одного (хоть и весомого) разработчика. Хотя и он сам говорит, что «The short answer is that we don't know yet» :)
                Но вы правы, о KDE5 таки думают. Но пока ничего ведь конкретного.
          • НЛО прилетело и опубликовало эту надпись здесь
              0
              Если платформы предлагают разные возможности, то вроде логичное решение.
                +5
                Qt задумывался для сближения платформ, а сильные расхождения в API этому точно не поспособствуют.
              +9
              Инициатива из серии: «А давайте испортим единственный вменяемый десктопный native GUI-framework и сделаем еще один WPF».
              Страшновато.
                +3
                Разработчики Qt пытаются/хотят идти «в ногу со временем».
                И я бы сказал не «ещё один WPF», а его кросс-платформенная альтернатива.
                Простите, что в этом плохого?
                Всё новое всегда страшновато и это не значит, что нужно топтаться на месте.
                  +3
                  Существует масса критики в адрес WPF, в качестве примера как правило вспоминают историю с клиентом Evernote.
                  Посмотрим, что получится у Qt.
                    0
                    У каждого фреймворка есть специфика, нельзя один и тот же инструмент применять во всех сферах. Для большинства десктоп-приложений WPF удобен и красив как с точки зрения разработчика, так и с точки зрения пользователя.

                    Опять же, насколько я помню, Evernote критиковали не столько скорость работы приложения, сколько время его запуска. Это критично в основном для приложений, стоящих в автозагрузке. Для всех остальных приложений уже давно придуманы Splashscreen.

                    Тем более, что Qt имеет одно преимущество. В тех узких местах, где не устраивает производительность QML — используй всю мощь C++ и QWidgets.
                      +2
                      А что за история с Evernote? Я не в курсе :) Интересно.
                  +1
                  Учитывая, что «Separate all QWidget related functionality into its own library», все-таки оставят старый способ. Вопрос нативности внешнего вида при отрисовке новым способом(QWidgets will be layered on top of the scene graph (not the scene graph on top of QWidgets as is currently done with Qt 4) остается открытым.
                    +3
                    Вроде, по скринам QML компоненты выглядят нормально
                    image

                    Надеюсь хуже не станет.
                  +2
                  Качество 2D отрисовки OpenGL/DirectX заметно хуже программной. Особенно это заметно на шрифтах.

                  Не очень понятно как они собираются с этим боротся, или же они надеются что к моменту релиза все мониторы будут с разрешением 200-300 dpi.
                  • НЛО прилетело и опубликовало эту надпись здесь
                      +1
                      Да, только теперь это будет не true way.
                      • НЛО прилетело и опубликовало эту надпись здесь
                        • НЛО прилетело и опубликовало эту надпись здесь
                            +2
                            На моём «атомном» нетбуке с NVIDIA ION2, начиная с версии Qt 4.7.2, QML начал подтормаживать на анимациях, хотя версия 4.7.1 работает на ура. Ну а вообще для графического интерфейса и интерпретация неплохо работает. В любом ведь случае за qml-компонентами фактически стоят С++-классы. Когда Qt Quick ещё был в beta-стадии, я уже под Symbian его пытался юзать, и ничего не тормозило.
                            • НЛО прилетело и опубликовало эту надпись здесь
                                0
                                Да вот давно уже хочу, но всё руки не доходят поставить на винде git :)
                              +1
                              Кстати, согласен. Не знаю как другим, мне-таки немного неприятен код на QML. Во всяком случае сейчас. Когда смотришь на код где только C++ становится приятно. Может я просто мало работал с QML, Но вот ассоциации закрепились.
                                0
                                интерпретатор в QtQuick'е довольно реактивный, но у вас же не вся логика приложения находится в гуе?) и наиболее затратная часть по процессорному времени — отрисовка, полностью возложенна на C++, так что потерь в скорости почти нет, по крайней мере они незаметны обычным пользователям
                            0
                            Интересно увидеть HTML5 в качестве еще одной платформы.
                              0
                              Видимо будет в GNOME 4 :)
                            • НЛО прилетело и опубликовало эту надпись здесь
                                +1
                                лучше помогайте пилить Qt 5 — полезнее и перспективнее будет)
                                +1
                                Сколько времени удивляюсь зачем они привязались к JavaScript? Есть QT-шные бинды и под Java и под Python, но тянут JavaScript…
                                  +1
                                  потому что уже давненько QtScript входит в состав Qt, а раз он туда входит — то почему бы не заюзать?
                                  при этом стоит заметить, что QtScript не тянет за собой внешние зависимости, как это делали бы биндинги для Java/Python/Ruby/etc.
                                  далее, QtScript базируется на JavaScript движке WebKit, который тоже с версии Qt 4.5 входит в состав платформы, так что все логично и предсказуемо — новое решение (QtQuick) базируется на ранее созданных (QtScript)
                                    0
                                    Зачем человеку, который писал все время на С++ переходить на JavaScript, несмотря на его бурное развитие? Как писали выше это уже будет не «true way». Таким образом привлекаем web developers, но отпугиваем старых приверженцев.

                                    Лично я, не вижу четких причинно-следственных связей почему выбрали развитие именно в этом направлении, сам я писал еще на первых версиях QT, а потом сразу под Symbian, переход к QML как концепции c декларативным описанием порадовал(хотя есть же XAML как в WP7, XML как в Android).Несмотря на это остался приверженцем С++.
                                    Создается ощущение, что больше контролируешь процесс и можешь допилить функционал именно как тебе надо.Еще одна надстройка скрывает зависимости.
                                      0
                                      Так никто же Вам не запрещает использовать С++. Пользуйтесь на здоровье. Я вот тоже ярый адепт С++ (что видно хотя бы по моей аватарке), но QML мне понравился, в частности тем, что он отлично расширяется из С++.
                                        +2
                                        тогда, к слову, мне непонятно притягивание сюда биндингов для Java/Python — зачем они C++ программисту?

                                        Qt Markup Language — это лишь способ задания интерфейса, по аналогии с уже существующими *.ui файлами, никто не заставляет вас реализовывать в ней логику — это преподносится как «плюшка», никто не заставляет вас описывать интерфейс именно на QML — все классы, или почти все, доступны через C++ API и являются банальными наследниками уже известного QGraphicsObject — пользуйтесь на здоровье.
                                        По сути использование QML должно сводиться к описанию самого интерфейса (где и как должны распологаться кнопки/поля) в QML — что можно сделать и через QtDesigner, и описанию логики приложения в C++, что совершенно никак не противоречит современному положению дел с описанием интерфейсов через *.ui файлы

                                        P.S. «QT» — это «QuickTime», мб вы имели в виду все таки «Qt», которое не является аббривиатурой?
                                          0
                                          Я прекрасно понимаю, что такое декларативные языки и в частности QML. Вопрос в том, зачем логику реализовывать в файле описания? Это может стать камнем преткновения, особенно для начинающих программистов.

                                          Опять же, в оригинале текста, четко прослеживается мысль, что это не «плюшка», это настоятельная рекомендация к действию.

                                          Биндинги я привел потому, что на мой взгляд, такой поддержкой JavaScript пытаются привлечь разработчиков из среды web development.Сделайте бинды для JavaScript и не внедряйте его внутрь, кто захочет тот разберется как использовать, а то так можно намешать много чего.

                                          P.S: Да, я знаю различия между «QT» и «Qt».

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