Себастьян Кюглер (Sebastian Kügler), вице-президент организации KDE e.V., опубликовал (http://vizzzion.org/blog/2013/01/the-road-to-kde-frameworks-.../) отчёт о текущем состоянии проекта KDE Frameworks 5 и нового пользовательского окружения Plasma 2, продолжающих развитие технологий KDE на базе Qt5 (http://www.opennet.me/opennews/art.shtml?num=35649), использующих OpenGL для рендеринга и способных работать как поверх традиционного X-сервера, так и поверх дисплейного сервера Wayland.
Вместо монолитного набора базовых библиотек в KDE Frameworks 5 будет воплощена новая модульная структура, оформленная (http://www.opennet.me/opennews/art.shtml?num=31420) в виде взаимодействующих друг с другом независимых фреймвоков, которые можно будет использовать в том числе и в сторонних Qt-проектах, не привязанных к KDE. Кроме того, в рамках проекта планируется (http://www.opennet.me/opennews/art.shtml?num=31059) выделить общую полезную функциональность, расширяющую возможности Qt и не связанную внешними зависимостями, и добиться её включения в состав Qt.В настоящее время уже завершена работа над тремя из семи базовых задач, поставленных перед разработчиками KDE Frameworks 5. KDE Frameworks 5 уже успешно компилируется с использованием Qt 5.0 и обеспечивает запуска базовых системных сервисов (kdeinit5). Тем не менее, ещё не все зависимости, необходимые для работы KDE, портированы на Qt 5. Продолжается работа по переработке системы сборки (модуляризация настроек и макросов CMake). На 50% выполнена работа чистке kdelibs и подготовке к разбиению на отдельные модули, в расчете один модуль на каждую библиотеку.
Использование в Plasma и KWin новых возможностей библиотеки Qt5 позволяет обеспечить их работу на более современных графических стеках, таких как Wayland, и подразумевает уход от отрисовки с использованием X11 к рендерингу на базе OpenGL. Технология QtQuick2, используемая для построения оболочки Plasma 2, предоставляет дополнительные средства в разработке, позволяя в полной мере использовать возможности графического оборудования, реализовать новые визуальные элементы и упростить написание дополнений для рабочего стола. Переход на Qt5, который несёт собой нарушение бинарной и программной совместимости, является хорошим поводом для реализации архитектурных изменений в Plasma 2 и переработки Plasma API. В итоге, разработчикам будет предложен Plasma Quick, сочетающий методы QtQuick с рядом компонентов для поддержки визуальных тем, контроля отрисовки, интернационализации, доступа к данным, конфигурации и взаимодействии с оборудованием.
В настоящее время, уже идёт работа по переводу реализации пользовательского интерфейса на использование QML. В рамках библиотеки libplasma2 представлен новый API и осуществлён перевод библиотеки Plasma и runtime-компоненты с использования QGraphicsView на QML. Тем не менее, это только вершина айсберга и для
полного завершения работы требуется выполнить очень много задач, в том числе выполнить портирование на QtQuick2, перевести движок скриптования с QScriptEngine на QDeclarativeEngine, создать новую оболочку, портировать виджеты с QGraphics* на QML.
Для разработки плазмоидов и апплетов, независимо от того на каком языке программирования они написаны, в Plasma 2 будет допустимо только использование QML, поддержка интерфейса на базе QGraphicsWidget прекращена. Апплеты будет рекомендовано создавать на чистом QML, для расширенных функций будет допустимо создание комбинированных апплетов на C++ и QML. В настоящее время уже завершено портирование на QML виджетов System tray, pager, notifications, device notifier, battery, lock/logout, weather, Wallpaper, Containment support. На разных
стадиях (http://community.kde.org/Plasma/QMLPorting) портирования находятся: Taskbar, Folderview, Desktop containment, Calendar, Kickoff, KRunner.Из этапов развития KWin называется:
- Обеспечение работы KWin поверх Qt5 и адаптация к работе с KDE Frameworks 5. Работу планируется завершить к релизу KDE 4.11, при этом KWin не будет зависеть от Qt 5 до времени, пока KDE не будет переведён на KDE Frameworks 5;- Обеспечение возможности рендеринга через модули KMS без зависимости от X-сервера. Работу планируется завершить к релизу KDE 4.11, который по прежнему будет запускаться поверх X-сервера, но будет подготовлен экспериментальный прототип для работы поверх KMS.
- Реализация возможности работы KWin в качестве композитного сервера Wayland. Работу планируется завершить к релизу KDE 4.12, в котором по прежнему по умолчанию будет задействован X-сервер, но появится опциональная возможность поддержки Wayland, если к этому времени будут готовы компоненты KDE Frameworks 5.
- В далёком будущем ожидается исключение X11 из зависимостей, что позволит собрать KDE Plasma Active без X-ов. Планов по полному прекращению поддержки X11 нет.
URL: http://vizzzion.org/blog/2013/01/the-road-to-kde-frameworks-.../
Новость: http://www.opennet.me/opennews/art.shtml?num=35910
>Обеспечение возможности рендеринга через модули KMS без зависимости от X-сервера. Работу планируется завершить к релизу KDE 4.11, который по прежнему будет запускаться поверх X-сервера, но будет подготовлен экспериментальный прототип для работы поверх KMS.не понял. KWayland велосипедим?
(Устало)Wayland от Weston'а аноним, конечно же, не отличает...
не придирайся, Weston - реализация вяленого, которого так хочется всуе вспомнить некоторым)
weston - реализация wayland
а реализация вяленого - стояк
Многие же орали "X11 не нужен!". Но у этого X11 была хоть какая-никая сетевая прозрачность. Пусть даже по современным представлениям и убогая. Ну раз не нужно, то кдешники хотят показать, что Wayland, тем более, не нужно. Т.е. всю графику можно реализовать посредством прямой работы через KMS средствами KDE технологий. А Вяленый тут лишняя прокладка.
Да пусть KDE рендерится себе через KMS сколько угодно. Отстальным-то прикладухам, на GTK3/EFL/qt5, например, что с того? Если пацаны на новый год плотно покумарили, это не значит, что нужно соглашаться с их поехавшим мировоззрением. Пусть себе резвятся, может даже KDE-only сетевую прозрачность запилят, флаг им в руки.
Цель Desktop Environment же не рисование кнопок на javascript через OpenGL и не постоянное переписывание одних и тех же плазмоидов с одними и теми же ошибками на всё новые и новые API. Цель Desktop Environment - делать каждодневное общение с компьютером удобным. В этом плане интересно планируются какие-то улучшения? Хотя бы до возможностей KDE3? Риторический вопрос... Разработчикам же некогда заниматься такими глупостями, они портируют KDE с Qt на Qt...
>Разработчикам же некогда заниматься такими глупостями, они портируют KDE с Qt на Qt...ну почему же, они еще активно встраивают пожираки памяти, процессора и диска. и кстати, эти как-раз работают без глюков.
// Runs KDE 4.9.5 @ ArchLinux 64bit с полным набором аконадей, непомуков, и стрингов на виртуозах. Чисто хохмы ради. Даже Kontact использую.
Сколько оперы жреть?
Ну мне, например, четвёртый КДЕ кажется самым красивым и удобным из всех перепробованных ДЕ, я на нём сижу и не жалуюсь особо, ресурсов разве что можно было бы потреблять поменьше, но я как-нибудь переживу, надо будет, выберу для железа с 1ГБ и меньше ОЗУ что-нибудь полегче.
А если вам надо "возможности КДЕ3", вам их любезно делают в Trinity Desktop.
akonadi и nepomuk выруби, и на гигабайте RAM в своп не будет вылазить
Да ладно, что те аконади с непомуком всем жизнь отравили? )
Файрфокс и Хром - вот две лютые пожиралки памяти, особенно последний, особенно, если на посещаемом сайте забыли отключить вывод отладки в консоль.
Интересно, каких же возможностей КДЕ3 Анониму не хватает в четверке?
Интерфес настройки параметров монтирования флешек. В четвёртой версии опции mount вкомпилированы в C код.
А что это такое и зачем это нужно? Я не шучу, за все годы работы под линуксом я о таком слышу в первый раз. И да, это все нельзя вписать в fstab?
Складывается ощушение что ваши годы работы ограничены тремя штуками :)
И к чему привязываться в fstab, если всё может меняться (метка/имя девайса/UUID)? Тем более что и для известных девайсов fstab тут скорее всего проигнорируется, не в курсе, смотрят ли туда udisks.
Про модульность я понял, если метнусь на ГНОМ и захочу чего-нибудь КЕДово то не придется много тащить. А если на КЕДах остаюсь какие плюсы ? Памяти будет меньше есть, стабильность повысится или как ?
> Обеспечение возможности рендеринга через модули KMS без зависимости от X-сервера.Это будет значимый прирост производительности или на уровне погрешности ?
Можно предположить, что стабильность возрастёт, т.к. пересборка будет происходить быстрее.
> Про модульность я понял, если метнусь на ГНОМ и захочу чего-нибудь КЕДово
> то не придется много тащить. А если на КЕДах остаюсь какие
> плюсы ? Памяти будет меньше есть, стабильность повысится или как ?По поводу памяти - вряд ли что-то поменяется, мейнтейнерам добавится головняка в несколько сотен пакетов.
>> Обеспечение возможности рендеринга через модули KMS без зависимости от X-сервера.
> Это будет значимый прирост производительности или на уровне погрешности ?Ну это как на складе по оптовым ценам тариться - если убрать жадного и неповоротливого посредника - всё стоит дешевле, а тратятся те же суммы, бо накупается всего сразу и побольше.
В общем свистелок добавится - эвон на кьюти какие симпатяшки демонстрируют в несколько строк кода...
Ну сколько можно, qml... js... Вот на js со строгой типизацией, без сборщика мусора и с оператором delete я бы ещё согласился. Все равно, что есть тот сборщик, что нету, оно постепенно набирает вес, а сбавлять даже и не думает. Новые кеды будут в 2 раза больше жрать чем старые, ради чего? Объясните мне, идиоту. Сказки про ололо-возможности и гибкие интерфейсы мне слушать не хочется.
> Вот на js со строгой типизацией, без сборщика мусора и с оператором delete я бы ещё согласился.это вы так тонко описали С++?
Плазма падала, так как была написана поверх QGraphicsView,
которая написана поверх стека QWidget. А сцена сама по себе реализована не очень удачно-я когда с ней работал, матерился дико-баг на баге и багом погоняет.
Сейчас разработка сцены прекращена (как и модуля QtWidgets), все фиксы-за счет энтузиастов.
QML же технология новая, реализована без стека qwidget и по сему работает быстрее, чем сцена (когда-то давно они выкладывали бенчмарки, если брать сцену без ОГЛ за 1.0 (х кадров в сек) то сцена с ОГЛ ускорением - будет 1.2 (1.2*x), а новая технология дает уже двукратный прирост (2х). То есть если раньше можно было выжать 50-60 фпс, то сейчас все 120. Нафига столько? Столько не надо, но при том же кол-ве фпс ресурсы жруться вдвое меньше.
Сам жс скрипт jit-компилируется и предназначен для выполнения простых вещей, все сложные расчеты о5 же надо делать на с++. Так что вряд ли скрипт будет тормозить.
Кроме того, отсутствие стека qwidget и qpainter упрощает код нового декларативного движка, а значит плазме не придется затыкать баги qt, как сейчас.
То есть у кде выбора особо нет-либо использовать глючную, медленную, никем не поддерживаемую сцену, либо перейти на быстрый, развивающийся qml.
> Сейчас разработка сцены прекращена (как и модуля QtWidgets), все фиксы-за счет энтузиастов.А Qt разве не целиком силами энтузиастов развивается? Nokia же прекратила по моему его развитие и отдала в сообщество.
man Digia
Главное и чему я рад это то, что разработка KDE5 будет вестись параллельно с развитием и поддержкой стабильной четвертой ветки, а когда будет все готово, у каждого будет возможность решать переходить или обождать. Похоже выводы сделаны и это хорошо!
Эх, годика 2 так ещё не видать нам Вяленого, видимо
> Эх, годика 2 так ещё не видать нам Вяленого, видимоДа ладно, все его уже видели - сало як сало )))
>Работу планируется завершить к релизу KDE 4.11Рад что они продолжают разработку 4-ой ветки.
Пусть уж года 2 пилят KDE 5, но не повторяют ошибки KDE 4, который юзать было можно только с версии 4.3+.
Но главное, что они продолжаю развитие 4-ой ветки (которое ранее планировалось прекратить после 4.10), и это здорово!
> Пусть уж года 2 пилят KDE 5, но не повторяют ошибки KDE 4, который юзать было можно только с версии 4.3+.И тогда стабильная версия будет через 10 лет. Без массового внедрения баги не найдут.
Они уже перешли на SQLite вместо MySQL?Или MySQL до сих пор нужен для KDE - хотя KDE использует хорошо если 1% из возможностей MySQL...
Вопрос переадресован мейнтейнерам твоего дистрибутива.
неа -- он нужен аконади, а она КДЕ... ::::# aptitude purge mysql-server-core-5.5
Наступні пакунки будуть ВИДАЛЕНІ:
mysql-server-core-5.5{p}
0 пакунків оновлено, 0 нових встановлено, 1 видалено і 0 не оновлено.
Потрібно отримати 0 b архівів. Після розпакування буде звільнено 20,0 Mb.
Наступні пакунки мають незадоволені залежності:
akonadi-backend-mysql : Залежності (Depends): mysql-server-core котрий є віртуальним пакунком.
Ці залежності можуть розв'язати такі дії:Видалити такі пакунки:
1) akonadi-backend-mysql
2) akonadi-server
3) akregator
4) kaddressbook
5) kde-plasma-desktop
6) kde-standard
7) kde-workspace
8) kde-workspace-bin
9) kdepim-runtime
10) kdeplasma-addons
11) kmail
12) knotes
13) kopete
14) korganizer
15) kscreensaver
16) kscreensaver-xsavers
17) libkdepim4
18) libkopete4
19) libmessagelist4
20) plasma-dataengines-workspace
21) plasma-desktop
22) plasma-runners-addons
23) plasma-scriptengine-python
24) plasma-scriptengines
25) plasma-widget-lancelot
26) plasma-widgets-addons
27) plasma-widgets-workspace
28) python-kde4
29) software-properties-kde
30) system-config-printer-kde
31) task-kde-desktopLeave the following dependencies unresolved:
32) kde-workspace-bin recommends plasma-scriptengines
33) kscreensaver-xsavers recommends kscreensaver (= 4:4.8.4-5)
34) libkopete4 recommends kopete (= 4:4.8.4-1+b1)
35) plasma-widgets-addons recommends plasma-widget-lancelot
36) task-desktop recommends task-gnome-desktop | task-kde-desktop | task-lxde-desktop | task-xfce-desktop
Прийняти цей розв'язок? [Y/n/q/?]
> Они уже перешли на SQLite вместо MySQL?
> Или MySQL до сих пор нужен для KDE - хотя KDE использует
> хорошо если 1% из возможностей MySQL...зависимости Аконади который нужен КДЕ :::
# aptitude show akonadi-server
Пакунок: akonadi-server
Стан: встановлений
Автоматично встановлений: так
Версія: 1.7.2-2
Пріоритет: додаткові (extra)
Розділ: net
Супроводжуючий: Debian Qt/KDE Maintainers <debian-qt-kde@lists.debian.org>
Архітектура: amd64
Розмір в розпакованому стані: 2 195 k
Залежить: libakonadiprotocolinternals1 (= 1.7.2-2), libboost-program-options1.49.0 (>= 1.49.0-1), libc6 (>= 2.4), libgcc1 (>= 1:4.1.1), libqt4-dbus (>=
4:4.6.1), libqt4-network (>= 4:4.6.0), libqt4-sql (>= 4:4.6.0), libqt4-xml (>= 4:4.6.0), libqtcore4 (>= 4:4.8.0), libqtgui4 (>= 4:4.6.0),
libsoprano4 (>= 2.2.69), libstdc++6 (>= 4.4.0), akonadi-backend-mysql (= 1.7.2-2) | akonadi-backend-sqlite (= 1.7.2-2) |
akonadi-backend-postgresql (= 1.7.2-2)--- то есть уже сейчас или MySQL или POSTGRESQL или SQLite
Модульность это хорошо, только не забыли бы выделить аконади с непомуками в отдельные легко отключаемые модули!
зависимость от QtQuick2.0 пугает, который в свою очередь зависит от GLES2 шейдеров и такого, понятно что в крайнем случае через новую месу будет работать, но всё же
Самый большой недостаток KDE 4 - здоровенный kdelibs. В KDE 5 обещали разбить эту здоровенную библиотеку на более мелкие, и тогда будет менее громоздко ставить некоторые приложения из KDE в Xfce. Честно говоря, я бы перешел на KDE 5 чуть раньше, на стадии альфа-бета версии, когда ее исходники выложат и ебилды напишут. И если ей можно будет в тот момент пользоваться нормально, то почему бы и нет?