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)

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

Закостенелые иксофилы, говорите...

Если вялендофилы хотят сломать совместимость и отбросить линукс на 10 лет назад, то протестовать против этого - не закостенелость, а как минимум инстинкт самосохранения.

Закостенели, если уж на то пошло, сами вялендофилы. Причём хорошо так закостенели, лет на 10-15. Кричат про какие-то тормоза иксов. Это до вас, друзья мои, дошло, как иксы работали во времена ОЗУ 32 мегабайта и меньше? Тогда да, иксы тормозили. А линукс с иксами по производительности начисто сливал глючной, ненадёжной, но чертовски неприхотливой Windows 95. Не говоря уж про OS/2, которая к тому же была ещё и нормальной ОС. Но тогда почему-то никто выпиливать иксы не собирался.

Зато собрались сейчас, когда иксы давно уже не тормозят. Тормозят монструозные IDE. А борются почему-то с иксами. Линукс только-только начал штурмовать десктоп - и тут появляется вяленд.

hobbit ★★★★★
()

Присоединяюсь, спасибо за новость.

gv
()

An architecture based on Qt5 and Wayland makes it possible to use a more modern graphics stack

Архитектура, основанная на Qt5 и Wayland, делает возможным использование большего количества современных графических стеков

Я думаю тут нужно поправить на:

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

// Тред не читал.

gv
()
Ответ на: Закостенелые иксофилы, говорите... от hobbit

Насколько понимаю у некоторых иксы начали тормозить недавно. Сглаживание шрифтов, обилие графики и т.д. дают о себе знать. Иксы не были рассчитаны на работу в таком режиме. У меня практически все это отключено, но даже при работе через adsl возникают некоторые поблемы (дело не только в иксах, например dbus не работает по сети).

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

Разумеется переписать все приложения на другой протокол невозможно. Насколько понял разработчики wayland-а хотят встроить в него иксы и запускать их по требованию. Т.е. сделать так же, как это реализовано в MacOS.

Не являюсь поклонником wayland-а, мне больше нравится идея Y Window System, но, с учетом неизбежных издержек, возможно это наиболее оптимальное решение.

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

Зачастую труд людей ведет в таакую жжжж, чтр хочется остановиться, развернуться и пойти назад. 100500 новостей на лоре которые только огорчают и вот первая для меня которая радует

disee ★★★
()
Ответ на: Закостенелые иксофилы, говорите... от hobbit

Тормозят монструозные IDE

DE, то бишь? Нормальная DE была - G2. Но это опенсорс, здесь вероятность появления отстоя в качестве мейнстрима в разы выше, чем в той же МС. В качестве примера, они признали висту провалом и выпустили семерку, которой были все довольны. Признают 8 провалом и выпустят девятку, которой будут все довольны. В мире линуксов нет обратного хода, нет цены уже готовым наработкам. Ценится лишь код, а не то, что он делает.

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

это опенсорс, здесь вероятность появления отстоя в качестве мейнстрима в разы выше, чем в той же МС.

Э, нет. Я критикую вахтёров, но призывать грабителей на помощь против вахтёров не собираюсь.

В качестве примера, они признали висту провалом и выпустили семерку, которой были все довольны.

Ну вообще-то, я могу вспомнить KDE 4.0, от которого все плевались. После этого над четвертокедами была произведена большая работа. Тебя не устраивает то, что результат не назвали KDE 5.0? Точно так же, семёрка - это хорошо допиленная виста.

В мире линуксов нет обратного хода, нет цены уже готовым наработкам.

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

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

Хватит объявлять тостерами все девайсы ниже i7.

Две цистерны чая этому господину.

Здесь согласен.

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

Который должен обработаться зависшим приложением. 8^E~

Таскбар обрабатываться приложением? ШТО?

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

Насколько понимаю у некоторых иксы начали тормозить недавно. Сглаживание шрифтов, обилие графики и т.д. дают о себе знать. Иксы не были рассчитаны на работу в таком режиме. У меня практически все это отключено, но даже при работе через adsl возникают некоторые поблемы (дело не только в иксах, например dbus не работает по сети).

Это всё не проблемы иксов, а тех самых говно-тулкитов. На вяленде в говнотулкитах не изменится ни-че-го.

Что до сети, то иксы конечно не слишком хороши для сети, если сравнивать с RDP. Но никто же не говорит «мужики, давайте разработаем приличный открытый аналог RDP с шахматами и поэтессами». Слышны только упоротые вопли о том, что сетевая прозрачность не нужна на микроволновках. (Видимо, те самые i7 как раз должны стоят на микроволновках, ага.)

Вообще как выше в треде было уже замечено, вяленд - это унылая попытка переизобрести графическую подсистему ондроеда. NIH-синдром у Штеуда и КрасноШляпы, и всё такое. Зачем? «Потому что гладиолус.»

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

Это всё не проблемы иксов, а тех самых говно-тулкитов. На вяленде в говнотулкитах не изменится ни-че-го.

Вот-вот.

это унылая попытка переизобрести графическую подсистему ондроеда

Вот интересно - а не пытался ли кто-нибудь впрямую применить андроид на десктопе?

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

Вот интересно - а не пытался ли кто-нибудь впрямую применить андроид на десктопе?

Пытались и достаточно давно. http://24gadget.ru/1161052386-motorola-hmc3260-pervyy-v-mire-android-desktop.... Видел подобное устройство, китайский нонейм. Если для кого-то основной функцией ос является запуск браузера вполне можно использовать.

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

Это всё не проблемы иксов, а тех самых говно-тулкитов. На вяленде в говнотулкитах не изменится ни-че-го.

Надеюсь понятно, что создатели тулкитов не будут это исправлять, в т.ч. пилить сетевую прозрачность. Создатели wayland-а пошли несколько другим путем. Т.е. тулкит осуществляет рендеринг собственными силами, wayland в это не вмешивается.

Вообще как выше в треде было уже замечено, вяленд - это унылая попытка переизобрести графическую подсистему ондроеда. NIH-синдром у Штеуда и КрасноШляпы, и всё такое. Зачем? «Потому что гладиолус.»

Связи с андроидом не понял, но документации с обоснованием такого решения, в т.ч. от разработчиков иксов достаточно.

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

Надеюсь понятно, что создатели тулкитов не будут это исправлять, в т.ч. пилить сетевую прозрачность. Создатели wayland-а пошли несколько другим путем. Т.е. тулкит осуществляет рендеринг собственными силами, wayland в это не вмешивается.

Ну так и какая разница, кто именно не вмешивается в алгоритм рендеринга тулкита - иксы или вейланд? Результат абсолютно одинаков - тормоза.

Связи с андроидом не понял

Легковесный мультиплексор фреймбуфера, который не умеет ничего, кроме композиции прямоугольников - это собственно основа видеоподсистемы ондроеда. И на телефоне она смотрится вполне закономерно. Зачем этот обрубок нужен на десктопе - не ясно.

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

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

Кроме того, возможно удастся избавится от некоторых особенностей иксов. Например мне не нравится, что любое приложение может читать ввод другого. Чтобы это сделать в иксах Рутковской пришлось делать такую схему http://www.opennet.ru/opennews/pics_base/0_1346693729.png

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

Насколько понял убрав сетевую подсистему (либо сделав её опциональной) можно избавится от двойной буферизации

А где она в иксах? Я более того скажу - некоторая часть тормозов gtk (про qt не скажу, не в курсе) - это прямое следствие как раз отсутствия грамотной двойной буферизации, а не её наличия.

любое приложение может читать ввод другого

Если рассматривать решение именно в рамках развития иксов, то правильный вариант решения - токены авторизации клиентов и правила selinux. Т.е. иксы расширяемы до правильного решения. Правильного в том смысле, что администратор сможет разрешить «кому надо» читать ввод «кого надо», а всем остальным - запретить.

Другое дело, что никто не хочет этим заниматься, потому что линукс для троянов - это неуловимый Джо.

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

При чем тут тулкиты? Это происходит на другом уровне. Клиент и сервер общаются по сетевому протоколу.

Если рассматривать решение именно в рамках развития иксов, то правильный вариант решения - токены авторизации клиентов и правила selinux. Т.е. иксы расширяемы до правильного решения. Правильного в том смысле, что администратор сможет разрешить «кому надо» читать ввод «кого надо», а всем остальным - запретить.

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

So, let me stress this one more time: if you have two GUI applications, e.g. an OpenOffice Word Processor, and a stupid Tetris game, both of which granted access to your screen (your X server), then there is no isolation between those two apps. Even if they run as different user accounts! Even if they are somehow sandboxed by SELinux or whatever! None, zero, null, nil!

http://theinvisiblethings.blogspot.ru/2011/04/linux-security-circus-on-gui-is...

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

При чем тут тулкиты? Это происходит на другом уровне. Клиент и сервер общаются по сетевому протоколу.

Ты укажи на то место, где возницает двойная буферизация. Нормальный иксовый клиент оперирует пиксмапами сервера через xrender. Где оверхед?

До сих пор нормальных решений я не видел

Еще раз - решений нет, потому что ненужно. То самое лоровское «ненужно», хрестоматийное. Если представить, что у нас сейчас вдруг доля линукса на десктопе 30%, то сразу станет нужно, и через полгода выйдет грамотное, рабочее решение. Архитектура иксов не препятствует контролю доступа. В ней просто ничего не сделано на эту тему, потому что никогда этот вопрос в реальности не поднимался на достаточно серьёзном уровне.

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

Все данные между клиентом и сервером копируются, при этом используется либо TCP/IP, либо (для локальной машины) UNIX Domain Sockets. Других методов коммуникации (например использование общей памяти с передачей только указателей) не предусмотрено.

Еще раз - решений нет, потому что ненужно.

Тебя устраивает ситуация когда любое приложение (пусть это будет скайп, флеш и т.д.) могут читать пароли из браузера? Причем это невозможно отследить.

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

Других методов коммуникации (например использование общей памяти с передачей только указателей) не предусмотрено.

Здрасти. Приплыли. Уже лет 20 как используется разделяемая память. По сокету идут только управляющие команды.

Тебя устраивает ситуация когда любое приложение (пусть это будет скайп, флеш и т.д.) могут читать пароли из браузера? Причем это невозможно отследить.

У меня любое приложение и так читает любые мои данные, т.к. selinux-а на домашней машине нет, и любой сраный скайп может утащить хоть весь хомяк целиком. Именно поэтому у меня дома нет сраного скайпа. :)

Повторяю в третий раз для одарённых: решения этой проблемы в общем виде не существует в данный момент. При вяленде всё высокоуровневое IPC будет идти через dbus, и та же самая угроза просто вылезет на другом уровне.

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

Здрасти. Приплыли. Уже лет 20 как используется разделяемая память. По сокету идут только управляющие команды.

MIT-SHM был предложен в 1991 году, На данным момент практически не используется http://codesearch.debian.net/search?q=#include <X11/extensions/XShm.h> (это выборка по дебиану, с другими проектами ситуация аналогичная).

У меня любое приложение и так читает любые мои данные, т.к. selinux-а на домашней машине нет, и любой сраный скайп может утащить хоть весь хомяк целиком. Именно поэтому у меня дома нет сраного скайпа. :)

selinux в данном случае не поможет. Он может не дать открыть сокет, но если сокет открыт (для иксового приложения нужен доступ к сокету) передаваемые данные не контролируются.

Это может быть не скайп, а любой код с PPA или собранный на локальной машине.

Повторяю в третий раз для одарённых: ...

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

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

selinux в данном случае не поможет.

Спасибо, кэп, я говорил про доступ к файлам. Нахрен беспокоиться о незакрытой форточке, когда у дома нет стены? На всех дистрибутивах,где нет selinux или apparmor, уязвимость иксов никакой дополнительной опасности не несёт. Потому что у нас тут стены нет, ага.

Он может не дать открыть сокет, но если сокет открыт (для иксового приложения нужен доступ к сокету) передаваемые данные не контролируются.

Они могут контроллироваться иксами. Если иксы научить использовать политики безпасности через selinux или apparmor. Сколько раз повторить, чтобы дошло?

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

Уже многократно обжевывалось, что можно. Слушай, ну зачем ты так уверенно несешь чушь?

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

MIT-SHM был предложен в 1991 году, На данным момент практически не используется http://codesearch.debian.net/search?q=#include (это выборка по дебиану, с другими проектами ситуация аналогичная).

// Тяжкий вздох.

Ты сам по своей ссылке ходил? gtk2 и qt4. О, да. «Практически не используется». Парень... всё... иди займись матчастью. Это каждый раз одно и то же. Приходят вьюноши со взглядом горящим и начинают рассказывать о недостатках той или иной подсистемы линукса, об устройстве данной подсистемы при этом ничего не зная. Каждый день на ЛОРе, бесконечный как Санта-Барбара сериал. То про двойную буферизацию. То про команды OGL, которые «в иксах тормозят». То про то, что «современный тулкит не польузется возможностями иксов вообще». И так далее. Почему? Мне этот вопрос каждый раз не даёт покоя. Ну почему? Почему нельзя, прежде чем влезать в спор, почитать документацию? Не говорю уж исходники, но хотя бы документацию-то можно почитать...

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

Они могут контроллироваться иксами. Если иксы научить использовать политики безпасности через selinux или apparmor. Сколько раз повторить, чтобы дошло?

Показать код. Возможно я что то пропустил. Работающие реализации есть?

Ты сам по своей ссылке ходил? gtk2 и qt4.

Возможно у нас разные представления что называть использованием. Но, например в qt4 используется в одном месте (конфиги разумеется не учитываю) http://codesearch.debian.net/show?file=qt4-x11_4.8.2+dfsg-4/config.tests/x11/... . Т.е. я считаю, что в данном случае расширение не используется, но при сборке проверяется его наличие (это файл в config.tests).

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

Возможно у нас разные представления что называть использованием.

Предлагаю использованием называть использование:

$ ~/builds/x11trace/bin/xtrace gpicview | grep SHM
No display name to create specified, trying :9
Got connection from unknown(local)
000:<:0068: 16: Request(98): QueryExtension name='MIT-SHM'
000:<:0069:  4: MIT-SHM-Request(130,0): QueryVersion 
000:<:00b7: 16: MIT-SHM-Request(130,1): Attach shmseg=0x03200027 shmid=0x02898012 readonly=false(0x00)
000:<:00b9: 40: MIT-SHM-Request(130,3): PutImage drawable=0x03200025 gc=0x03200026 total-width=1536 total-height=64 src-x=0 src-y=0 src-width=48 src-height=48 dst-x=0 dst-y=0 depth=24 format=ZPixmap(0x02) send-event=false(0x00) shmseg=0x03200027 offset=0x00000000
000:<:010c:  4: MIT-SHM-Request(130,0): QueryVersion 
000:<:010e: 16: MIT-SHM-Request(130,1): Attach shmseg=0x0320003a shmid=0x028a0015 readonly=false(0x00)
000:<:010f:  8: MIT-SHM-Request(130,2): Detach shmseg=0x0320003a
000:<:0111: 16: Request(98): QueryExtension name='MIT-SHM'
000:<:0114: 16: MIT-SHM-Request(130,1): Attach shmseg=0x0320003c shmid=0x028a8015 readonly=false(0x00)
000:<:0115: 44: Request(25): SendEvent propagate=false(0x00) destination=0x0320003b event-mask=0 (generated) MIT-SHM-Completion(65) drawable=0x0320003b shmseg=0x028a8015 offset=0x00000000
000:<:0116:  8: MIT-SHM-Request(130,2): Detach shmseg=0x0320003c
000:>:0117: Event (generated) MIT-SHM-Completion(65) drawable=0x0320003b shmseg=0x028a8015 offset=0x00000000
000:<:011a: 16: MIT-SHM-Request(130,1): Attach shmseg=0x0320003e shmid=0x028b0015 readonly=false(0x00)
000:<:011d: 40: MIT-SHM-Request(130,3): PutImage drawable=0x0320003f gc=0x03200040 total-width=1000 total-height=500 src-x=0 src-y=0 src-width=1000 src-height=500 dst-x=0 dst-y=0 depth=32 format=ZPixmap(0x02) send-event=true(0x01) shmseg=0x0320003e offset=0x00e00000
000:<:012c: 16: MIT-SHM-Request(130,1): Attach shmseg=0x03200044 shmid=0x028b8017 readonly=false(0x00)
000:>:012d: Event MIT-SHM-Completion(65) drawable=0x0320003f shmseg=0x0320003e offset=0x00e00000
000:<:0132: 40: MIT-SHM-Request(130,3): PutImage drawable=0x03200045 gc=0x03200048 total-width=1536 total-height=64 src-x=16 src-y=0 src-width=16 src-height=16 dst-x=0 dst-y=0 depth=32 format=ZPixmap(0x02) send-event=false(0x00) shmseg=0x03200044 offset=0x00000000
000:<:013b: 40: MIT-SHM-Request(130,3): PutImage drawable=0x03200049 gc=0x03200048 total-width=1536 total-height=64 src-x=48 src-y=0 src-width=16 src-height=16 dst-x=0 dst-y=0 depth=32 format=ZPixmap(0x02) send-event=false(0x00) shmseg=0x03200044 offset=0x00000000
000:<:0144: 40: MIT-SHM-Request(130,3): PutImage drawable=0x0320004c gc=0x03200048 total-width=1536 total-height=64 src-x=80 src-y=0 src-width=16 src-height=16 dst-x=0 dst-y=0 depth=32 format=ZPixmap(0x02) send-event=false(0x00) shmseg=0x03200044 offset=0x00000000
000:<:014f: 40: MIT-SHM-Request(130,3): PutImage drawable=0x0320004f gc=0x03200048 total-width=1536 total-height=64 src-x=112 src-y=0 src-width=16 src-height=16 dst-x=0 dst-y=0 depth=32 format=ZPixmap(0x02) send-event=false(0x00) shmseg=0x03200044 offset=0x00000000
000:<:0158: 40: MIT-SHM-Request(130,3): PutImage drawable=0x03200052 gc=0x03200048 total-width=1536 total-height=64 src-x=144 src-y=0 src-width=16 src-height=16 dst-x=0 dst-y=0 depth=32 format=ZPixmap(0x02) send-event=false(0x00) shmseg=0x03200044 offset=0x00000000
000:<:0161: 40: MIT-SHM-Request(130,3): PutImage drawable=0x03200055 gc=0x03200048 total-width=1536 total-height=64 src-x=176 src-y=0 src-width=16 src-height=16 dst-x=0 dst-y=0 depth=32 format=ZPixmap(0x02) send-event=false(0x00) shmseg=0x03200044 offset=0x00000000
000:<:0194: 40: MIT-SHM-Request(130,3): PutImage drawable=0x03200063 gc=0x03200048 total-width=1536 total-height=64 src-x=208 src-y=0 src-width=16 src-height=16 dst-x=0 dst-y=0 depth=32 format=ZPixmap(0x02) send-event=false(0x00) shmseg=0x03200044 offset=0x00000000
000:<:019d: 40: MIT-SHM-Request(130,3): PutImage drawable=0x03200066 gc=0x03200048 total-width=1536 total-height=64 src-x=240 src-y=0 src-width=16 src-height=16 dst-x=0 dst-y=0 depth=32 format=ZPixmap(0x02) send-event=false(0x00) shmseg=0x03200044 offset=0x00000000
000:<:01a8: 40: MIT-SHM-Request(130,3): PutImage drawable=0x03200069 gc=0x03200048 total-width=1536 total-height=64 src-x=16 src-y=16 src-width=16 src-height=16 dst-x=0 dst-y=0 depth=32 format=ZPixmap(0x02) send-event=false(0x00) shmseg=0x03200044 offset=0x00000000
000:<:01b1: 40: MIT-SHM-Request(130,3): PutImage drawable=0x0320006c gc=0x03200048 total-width=1536 total-height=64 src-x=48 src-y=16 src-width=16 src-height=16 dst-x=0 dst-y=0 depth=32 format=ZPixmap(0x02) send-event=false(0x00) shmseg=0x03200044 offset=0x00000000
000:<:01ba: 40: MIT-SHM-Request(130,3): PutImage drawable=0x0320006f gc=0x03200048 total-width=1536 total-height=64 src-x=80 src-y=16 src-width=16 src-height=16 dst-x=0 dst-y=0 depth=32 format=ZPixmap(0x02) send-event=false(0x00) shmseg=0x03200044 offset=0x00000000
000:<:01c3: 40: MIT-SHM-Request(130,3): PutImage drawable=0x03200072 gc=0x03200048 total-width=1536 total-height=64 src-x=112 src-y=16 src-width=16 src-height=16 dst-x=0 dst-y=0 depth=32 format=ZPixmap(0x02) send-event=false(0x00) shmseg=0x03200044 offset=0x00000000
000:<:01ce: 40: MIT-SHM-Request(130,3): PutImage drawable=0x03200075 gc=0x03200048 total-width=1536 total-height=64 src-x=144 src-y=16 src-width=16 src-height=16 dst-x=0 dst-y=0 depth=32 format=ZPixmap(0x02) send-event=false(0x00) shmseg=0x03200044 offset=0x00000000
000:<:01d7: 40: MIT-SHM-Request(130,3): PutImage drawable=0x03200078 gc=0x03200048 total-width=1536 total-height=64 src-x=176 src-y=16 src-width=16 src-height=16 dst-x=0 dst-y=0 depth=32 format=ZPixmap(0x02) send-event=false(0x00) shmseg=0x03200044 offset=0x00000000
000:<:01e0: 40: MIT-SHM-Request(130,3): PutImage drawable=0x0320007b gc=0x03200048 total-width=1536 total-height=64 src-x=208 src-y=16 src-width=16 src-height=16 dst-x=0 dst-y=0 depth=32 format=ZPixmap(0x02) send-event=false(0x00) shmseg=0x03200044 offset=0x00000000
000:<:01e9: 40: MIT-SHM-Request(130,3): PutImage drawable=0x0320007e gc=0x03200048 total-width=1536 total-height=64 src-x=240 src-y=16 src-width=16 src-height=16 dst-x=0 dst-y=0 depth=32 format=ZPixmap(0x02) send-event=false(0x00) shmseg=0x03200044 offset=0x00000000
000:<:01f4: 40: MIT-SHM-Request(130,3): PutImage drawable=0x03200081 gc=0x03200048 total-width=1536 total-height=64 src-x=16 src-y=32 src-width=16 src-height=16 dst-x=0 dst-y=0 depth=32 format=ZPixmap(0x02) send-event=false(0x00) shmseg=0x03200044 offset=0x00000000
000:<:01fd: 40: MIT-SHM-Request(130,3): PutImage drawable=0x03200084 gc=0x03200048 total-width=1536 total-height=64 src-x=48 src-y=32 src-width=16 src-height=16 dst-x=0 dst-y=0 depth=32 format=ZPixmap(0x02) send-event=false(0x00) shmseg=0x03200044 offset=0x00000000
Got connection from unknown(local)
000:<:0211: 40: MIT-SHM-Request(130,3): PutImage drawable=0x03200087 gc=0x03200040 total-width=1000 total-height=500 src-x=0 src-y=0 src-width=1000 src-height=500 dst-x=0 dst-y=0 depth=32 format=ZPixmap(0x02) send-event=true(0x01) shmseg=0x0320003e offset=0x00e00000
000:>:0218: Event MIT-SHM-Completion(65) drawable=0x03200087 shmseg=0x0320003e offset=0x00e00000

Показать код. Возможно я что то пропустил. Работающие реализации есть?

Уже раз пять повторил, что нету.

geekless ★★
()

Когда там уже Wayland станет оконным менеджером по-умолчанию в дистрибутивах ?

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