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)

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

Чтобы выкинуть иксы на мороз.

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

anonymous
()
Ответ на: комментарий от RR42

Падает иногда Dolphin и Amarok,

Amarok

Второй небось? Да он из трея не может развернутьсь не потеряв размер окна и всех элементов, баг старый а воз и ныне там. Ну а про возвращение табличного интервейса тут и без меня говорили. Сущевствование клементина и использование многими до сих пор версии 1.4.10 нам какбЭ намекает.

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

Я прочёл их статьи и сделал вывод о нужности Wayland. Пересказывать содержание не умеющим гуглить гиклиссу с анонимусом у меня нет желания.

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

ну а как там гтк программисты говорят «программа не должна сама запоминать размеры и положения окон этим должно заниматься ДЕ» в итоге все вечно то запоминает то нет, а реально работает это только в винде;(

//да я знаю что ты говоришь про qt и kde

bhfq ★★★★★
()
Последнее исправление: bhfq (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

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

Капча «corporated icycso» какбЭ намекает нам...

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

Даже иксорг разрабы работают над Wayland, а тут ты, весь в белом и на коне, ага. Не бугурти. Что за ретроградство? Все подготоваливаются, Wayland пилится. Или тебя уже сегодня заставили Wayland поставить?

То, что тебе и так хорошо никак не поменяет необходимости что-то менять.

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

Он еще сурова бета, до нормального применения ему как до луны пешком

И?

Kindly_Cat
() автор топика

Все плазмоиды, использующие C++, Ruby, Python, JavaScript и «Web API», должны быть переписаны на QML

Как страшно жить!

DNA_Seq ★★☆☆☆
()
Ответ на: комментарий от anonymous

хинт: производителям железяк не впёрлись железяки 5летней давности. а уже через 3 года на прилавках будет мало решений на которых такие оптимизации работают, ппоэтому всё переписывают и оптимизиуют под технологии завтрашние.

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

иксы старые. дальше и правда можно не говорить.

У меня вот стиральная машинка-автомат старая - больше 10-ти лет уже пашет. И еще столько же пропашет, дай бог. С электро-механическим управлением. В то время как нескучные девайсы с электронным управлением у знакомых дохнут периодически.
Дальше и в самом деле можно не говорить.

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

Дальше и в самом деле можно не говорить.

Действительно, слова тут ни к чему - идиотские аналогии вызывают только хохот :)

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

так мы вроде определились что графика нужна...

Какая графика? Свистопердящие переливающиеся менюшки на шейдерах?

Я еще понимаю, когда GPU используется по прямому назначению - в 3d-редакторах или играх. (Хотя лично мне и то, и другое без надобности.) Но это... Извините, детский сад.

Эргономика типичного десктопа за последние лет 5 не изменилась ни на грамм. Зато шейдерами греть атмосферу мы научились, это да. Понимаешь, улучшений именно интерфейса - их нет нихрена. Ради чего мне тогда ноутбук-печь?

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

Ну может хоть так до тебя дойдёт, что «старый» - аргументом не является и являться не может. Впрочем, нет, не дойдёт.

geekless ★★
()

Кстати как там дела у K3b, где версия 2.1 в которую обещали запилить исполизование KDEшных уведомлейи и прогрес бара, вместо своего велосипеда, а так же кучу других ништяков?

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

«старый» - аргументом не является и являться не может

В общем случае - нет. Например, старое вино лучше молодого. А в данном конкретном случае это вполне себе краткий аргумент, который детально развёрнут авторами иксов и вяленда.

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

Ого, кто-то ещё диски записывает? :)

// Оффтоп. Я вот прям щас записываю, блин. Притащили ноут семерочку накатить. Попытаюсь oem-лицензию восстановить, если это вообще возможно.

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

Приведи пример DE которое «летает» на старом железе. Возьмем для примера мою конфигурацию E2140 Pentium Core Duo 1,6 ГГц 800 MГц FSB 1M Cache, RAM DDR2 2Гб, мамка Асроковская под стать, все было куплено в 2007 за 275€ (в Португалии, выбирал из самого дешевого что было в обычных магазинах). Тот же KDE работает хорошо, но употребить термин «летает» не могу, дистрибы очень многие пробовал, Гента незначительно быстрее всех (но глубоко не оптимизировал). Да, видеокарту nvidia GForce 8400GS купил три года назад за 40€ дешевле уже небыло.

Buy ★★★★★
()
Последнее исправление: Buy (всего исправлений: 3)
Ответ на: комментарий от Darkman

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

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

Мне интересно как ты ставишь дистры имея скаченный DVD образ, а так же если есть задача писать диски по работе и этой функцие пользуются домашние. Например штатная магнитола CD/MP3 читает вайлики с диска USB нет, ваши предложения? Поменять авто или магнитолу не вариант.

anonymous
()
Ответ на: комментарий от Buy

Тут не из чего выбирать. Потому что «все хуже».

gpicview функционально идентичен eog, но работает на порядок быстрее.
lilyterm гораздо мощнее gnome-terminal, при том что использует тот же движок и обладает из-за этого аналогичной производительностью. (А поскольку новый gnome-terminal перешел на 3-й gtk, то lilyterm теперь еще и быстрее оказался, при по-прежнему прекрасных возможностях.)
Total commander превосходит по возможностям большинство линуксовых графических ФМ и при этом даже под вайном более отзывчив большиства из них.
Artweaver (опять же под вайном) мощнее и отзывчивее Gimp-а.
Построение миниатюр в thunar-е не тормозит и в acdsee 90-лохматого года не тормозило, а в наутилусе вешает к хренам программу на несколько секунд, а то и минут (может уже починили, не знаю; во второгноме было).
qterminal идентичен konsole, но не тянет за собой половину кед и не запускается по 10 секунд.
И так далее. Такие примеры можно бесконечно приводить.

Ну да, все DE - «к этому пришли». Только дело-то не в том, что где-то невозможно по объективным причинам обеспечить производительность для заданных фич, а в объективно-дерьмовом качестве кода. Ну какие к черту, например, объективные причины в том, что основным тормозом любого ФМ на gtk является говно-реализация виджетов treeview и iconview? Этот виджет функционально ничем не отличается от такового в макоси или даже 95-й винде. Он просто дико тормозит при отрисовке, вот и все отличия.

Вот к этому мы и пришли, да. Отберите компиляторы у идиотов, и всё будет хорошо.

geekless ★★
()
Последнее исправление: geekless (всего исправлений: 1)
Ответ на: комментарий от geekless

qterminal идентичен konsole, но не тянет за собой половину кед и не запускается по 10 секунд

Плакал.

Такие пуки можно бесконечно генерировать.

fixed

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

Как смищно, цепко, оригинально. Сразу видно - титан мысли :)

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

Дальше прочесть не осилил?

Осилил. И что ? Падение WM приведёт к падению display server'а поскольку это один процесс - отвалится сессия - получаем единую точку отказа. «In wayland the compositor _is_ the display server»

И поскольку это один процесс - количество кода в WM увеличивается очень прилично, учитывая что «программа без ошибок величина абстрактная» и то что хороший WM обязан уметь скриптование, то получается что ошибка в пользовательском скрипте может порушить всю сессию - зашибись архитектурка.

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

Фрактальчик, ты хоть раз найдёшь в себе силы ответить по существу, или так и будешь сливать и сливать без остановок?

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

You can think of Wayland as a toolkit for creating clients and compositors

И как это отменяет вот это:

The Wayland architecture integrates the display server, window manager and compositor into one process.

и единую точку отказа ?

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

Ага, после последнего обновления в генте он слетел, и так и не удалось выяснить, из-за чего. Пока qml-вариант gmail-нотификатора поставил

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

странно. У меня даже на убунте konsole около секунды запускается, а в генте было почти мгновенно. А artweaver надо будет посмотреть, интересно

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