LINUX.ORG.RU

Состояние и планы разработки KDE Frameworks 5 и Plasma 2

 ,


1

5

Интерфейс KDE следующего поколения будет работать на Qt5 (в Linux) поверх Wayland или Xorg в качестве графического сервера, отрисовка его переместится с системы виджетов X11 на OpenGL. Монолитные библиотеки будут разделены, зависимости — урезаны в пользу модульности.

Статус Frameworks 5.

Разработка KDE Frameworks 5, направленная на модулизацию API, в настоящее время протекает в пределах kdelibs и kde-runtime, упрощая их внутреннюю структуру и разделяя их на отдельные библиотеки.

Работы над Frameworks 5 содержат 7 «эпических» задач, 3 из которых уже выполнены:

  • Начальное взаимодействие и документация.
  • Слияние кода с Qt5.
  • Удаление дублирующихся с Qt классов и использование их Qt-альтернатив.

Над оставшимися 4 задачами протекает бурная работа:

  • Система сборки CMake: вливание в апстрим некоторых фич, модулизация настроек и макросов, портирование, пересмотр и переработка модулей поиска.
  • Очень большая и трудоёмкая задача по чистке kdelibs, которая, тем не менее, уже выполнена на 50%.
  • Слияние с Qt 5.1.
  • Модулизация kdelibs: один модуль на каждую билиотеку. 13 задач выполнено, 12 - в процессе, 8 пока находятся в состоянии TODO.

Развитие Plasma и KWin.

Архитектура, основанная на Qt5 и Wayland, делает возможным использование большего количества современных графических стеков, что подразумевает перенесение отрисовки с X11 на OpenGL. QtQuick2 (это QtQuick в составе Qt5) имеет очень приятный и расширяемый API. Переход Plasma на Qt5 повлечёт за собой нарушение бинарной и кодовой совместимости, что является хорошим поводом для глубокой переработки Plasma API и внедрения новых архитектурных решений в Plasma 2. В итоге разработчикам будет представлен Plasma Quick, сочетающий методы QtQuick с рядом компонентов для поддержки визуальных тем, контроля отрисовки, интернационализации, доступа к данным, конфигурации и взаимодействия с оборудованием.

В рамках библиотеки libplasma2 представлен новый API и осуществлён перевод библиотеки Plasma и runtime-компонентов с использования QGraphicsView на QML, который будет основой пользовательского интефейса Plasma 2. Тем не менее, это только вершина айсберга и для полного завершения работы требуется выполнить ещё много задач, в том числе произвести портирование на QtQuick2, перевести движок скриптования с QScriptEngine на QDeclarativeEngine, создать новую оболочку, портировать виджеты с QGraphics* на QML.

Планы на композитор KWin Plasma:

Композитор Plasma в терминологии Wayland означает использование KWin в качестве Wayland-композитора для рабочих пространств Plasma. KWin подвергнется модулизации и чистке кода. Он уже поддерживает QML, но некоторые механизмы, работающие посредством XAtoms, ещё не переработаны.

Главное направление развития KWin это портирование на Qt5, возможность работать вне X-сервера поверх KMS, напрямую используя аппаратные ресурсы. Следующий шаг - использование KWin в качестве композитора Wayland. Зависимости от X11 могут быть удалены когда исчезнет надобность в поддержке совместимости со старыми X11-приложениями, или может быть сделана в виде опциональной возможности.

Этапы развития KWin:

  • Работа KWin поверх Qt5: будет завершено к релизу KDE 4.11 (тем не менее, KWin не будет зависеть от Qt5 до тех пор, пока KDE не будет полностью переведено на KDE Frameworks 5.
  • Рендеринг через KMS вне X-сервера: будет завершено к релизу KDE 4.11, который по-прежнему будет запускаться поверх Х-сервера, но уже сможет в экспериментальном режиме работать через KMS.
  • Возможность работы KWin в качестве композитора Wayland: планируется завершить к релизу KDE 4.12, в котором по прежнему по умолчанию будет задействован X-сервер, но появится опциональная возможность поддержки Wayland, если к этому времени будут готовы компоненты KDE Frameworks 5.
  • В отдалённом будущем планируется исключение X11 из зависимостей, тем не менее, полного прекращения поддержки X11 не произойдёт.

Рабочее пространство Plasma.

Стратегия заключается в миграции плазмоидов на QML. Все плазмоиды, использующие C++, Ruby, Python, JavaScript и «Web API», должны быть переписаны на QML, но в случаях когда возможностей QML не будет хватать, будет обеспечена поддержка комбинированных QML/C++ плазмоидов. Большинство необходимых плазмоидов (таких, как «панель задач», «просмотр каталога», «содержимое рабочего стола», «календарь», «KRunner», «Kickoff» и т.д.) будут портированы на QML уже к релизу KDE 4.11, а некоторые плазмоиды («системный лоток», «уведомления», «подключение устройств» и т.д.) портированы уже.

Заключение.

Проект KDE Frameworks 5 реализуется полным ходом. Благодаря ему KDE SC станет более современным, лёгким и модульным, более удобным и приятным в использовании. Важно понимать, что никакого срочного перехода на KDE 5 не будет: по прежнему будет развиваться ветка KDE 4.x, и лишь когда все технологии KDE, включая сторонние приложения, будут полностью портированы — можно будет говорить о релизе KDE Frameworks 5.

>>> Подробности



Проверено: JB ()
Последнее исправление: cetjs2 (всего исправлений: 4)
Ответ на: комментарий от Darkman

Я бы не сказал

А я б сказал. Иксы у меня падали пару раз за последний год (главным образом из-за быстрого переключения между tty при запущенной в wine игрушке), а Compiz/Kwin не падали ни разу.

От мы и посмотрим как это будет реализовано

Вот именно. Видно будет.

Ышо какая

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

а. одинаковых декорация для разных тулкитов б. пользовательских пунктов в меню в. единого центра конфигурации г. кнопок в заголовке не предусмотренных автором приложения д. одинакового вида подсказок для кнопок в заголовке для разных тулкитов е. window tabbing аля kwin/fluxbox

Это что, нерешаемые задачи?

Kindly_Cat
() автор топика
Ответ на: комментарий от Kindly_Cat

Это что, нерешаемые задачи?

В случае Client Side Decorations практически нерешаемые или решаемые очень сложно - как, например, реализовать tabbing ? Переносить половину реализации WM в тулкит, и так для каждого тулкита ?

Darkman ★★★
()
Ответ на: комментарий от Kindly_Cat

Это что, нерешаемые задачи?

В рамках принятого сейчас подхода, это задачи решаемые следующие лет 10. Т.е. сначала придумываем себе сложность, а потом долго пытаемся найти время, чтобы её правильно решить. Очень в духе современного СПО.

geekless ★★
()
Ответ на: комментарий от Darkman

тащемто уже. те кто нет те в вяленого только через икс умеют.

Thero ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.