Представлен план подготовки Qt 5 и первые планы, касающиеся KDE 5

Разработчики из компании Nokia представили [1] детальный план [2] разработки проекта Qt 5. Значительные изменения будут внесены не только в функциональность, но в организацию процесса разработки. Если ветка Qt 4, выпущенная в 2005 году, развивалась в основном силами одной компании, то ветка Qt 5 будет изначально отличаться более открытым процессом разработки и предоставлением возможности активного участия в проекте представителей независимого сообщества. В процессе разработки Qt 5 не будет отличий в отношении к разработчикам из Nokia и участникам разработки, пришедшим извне. Первую бета-вервию Qt 5 планируют выпустить в конце нынешнего года, а финальный релизе в течение 2012 года.
Qt 5 рассматривается в качестве фундамента для продвижения новых путей разработки приложений. Несмотря на сохранение всех инструментов по созданию Qt-программ на языке C++, использование кода на C++ смещается в сторону разработки бэкендов для интерфейса, оформленного с использованием Qt Quick. Возможность выполнения Qt-приложений на C++ сохранится, но изменится фундаментальный подход к тому, как нужно создавать приложения. Новый подход подразумевает написание всех частей интерфейса пользователя на QML, а JavaScript становится основным языком для определения базовой логики работы интерфейса приложения. Более того, Qt-приложения могут быть полностью написаны на JavaScript, без использования C++. Подразумевается, что C++ будет задействован только для реализации критичных ко времени выполнения или излишне сложных частей программы.
Основные мотивы создания новой ветки Qt связаны с накоплением достаточно большого объема устаревшего кода, убрать который мешает необходимость обеспечения совместимости с прошлыми версиями. Избавившись от устаревшего кода, разработчики получат возможность полностью сосредоточиться на реализации функций, которые позволят максимально эффективно создавать приложения и пользовательские интерфейсы нового поколения.
Среди целей создания ветки Qt 5 названы:

• Более активное использование средств GPU-акселерации с целью увеличения производительности выполнения графических операций с минимальным потреблением системных ресурсов;
• Обеспечение средств для упрощения и ускорения разработки продвинутых приложений и пользовательских интерфейсов, в том числе с использованием QML и Javascript;
• Предоставление приложениям возможностей для полноценного взаимодействия с Web, например, возможность встраивания в любое Qt-приложение обработчиков web-контента и функций для взаимодействия с web-сервисами;
• Избавление от усложненности и большого объема кода, необходимого для поддержания и реализации портов Qt для новых платформ.

Ключевые архитектурые изменения Qt 5:

• Изменение архитектуры графического стека. В качестве центральных элементов новой архитектуры будут выступать Qt Quick и QML Scenegraph. Поддержка QPainter будет сохранена для выполнения расширенных функций, но не сможет быть использована в основном интерфейсе пользователя. Для работы Qt система должна будет поддерживать OpenGL (ES) 2.0. QWidgets будет отображаться поверх графической сцены, а не наоборот, как сейчас реализовано в версии Qt 4;
• Все порты Qt будут основаны на инструментарии Lighthouse [3], созданном с целью значительного упрощения переноса Qt на новые платформы. Lighthouse изначально оперирует более абстрактными категориями, чем текущие средства интеграции с оконными системами;
• Модульная структура [4] репозитория. Многие из подсистем Qt разрабатываются разными группами разработчиков, развиваются с повышенной интенсивностью или плотно зависят от сторонних проектов. При грамотном разбиении фреймворка на модули, подобные подпроекты смогут обновляться и поставляться независимо от других частей Qt. Модульная организация репозитория позволит обеспечить сборку отдельной библиотеки без загрузки и пересборки всех зависимостей. Разработчики интенсивно развивающихся подсистем QtWebKit и QtDeclarative получат возможность не ждать когда подтянется другой код и выпускать релизы значительно чаще;
• Выделение всех связанных с QWidget возможностей в отдельную библиотеку. Несмотря на то, что основанные на QWidget классы чрезвычайно важны для существующих приложений, общая тенденция ведёт к тому, что все пользовательские интерфейсы должны быть реализованы на QML. Отделение связанных с QWidget функций в отдельную библиотеку позволит в долгосрочной перспективе сохранить чистоту архитектуры Qt 5.

Первые выпуски Qt 5 будут доступны для небольшого числа платформ, например, для Wayland и X11 в Linux, Mac OS X и Windows. Дальнейшее число поддерживаемых платформ будет зависеть от активности сообщества, так как Nokia не заинтересована в портировании Qt 5 на все платформы, поддерживаемые ныне в Qt 4. Так как в Qt 5 будут внесены изменения в API, Nokia не исключает нарушения бинарной совместимости при возникновении такой необходимости. Разработчики не планируют повторять опыт обеспечения максимальной переносимости между ветками, ранее опробованный в процессе перехода от Qt 3 к Qt 4, считая что достаточно сохранения совместимости на уровне исходных текстов. Тем не менее, в процессе разработки будет сделано все возможное для избежания нарушения фундаментальных основ Qt 4 и упрощения миграции существующих приложений на технологии Qt 5.
В ответ на озвученные Nokia планы выпуска Qt 5, Аарон Сейго (Aaron Seigo), основной разработчик десктоп-оболочки Plasma из состава KDE4, опубликовал [5] заметку, в которой поднял вопрос необходимости выпуска KDE 5, возможно уже в следующем году. Релиз KDE 5 будет иметь эволюционный характер, напоминая по своей сути переход от KDE 2 к KDE 3. По мнению Аарона, в Qt 5 ожидаются слишком большие изменения, которые не позволят без нарушения совместимости интегрировать в KDE 4 новые технологии Qt. Тем не менее, работа по переводу приложений на использование технологии декларативного описания интерфейса Qt Quick [6] уже достаточно давно ведется в KDE. В частности, на базе подобных технологий уже развиваются проекты libplasma2 и Plasma Active [7].
Положительным моментом также является то, что основная часть платформы KDE базируется на собственных библиотеках и runtime-компонентах, которые не потребуется переписывать, как было сделано в случае подготовки KDE 4. Несмотря на то, что в процессе создания KDE 5 не придется проводить глобальный реинжиниринг архитектуры проекта, у разработчиков появится шанс еще раз проанализировать и оптимизировать связь всех компонентов платформы. Из подсистем, которые потребуют значительной переработки, отмечаются библиотеки для формирования пользовательского интерфейса (libkdeui) и KIO. Более подробно вопросы перехода KDE на Qt 5 будут рассмотрены на ближайшем саммите разработчиков проекта.