LINUX.ORG.RU

Ситуация с Wayland: факты о X и Wayland.

 ,


32

7

Это вольный перевод статьи, намедни размещённой на phoronix. Оринальная статья — обзор недостатков, их исправлений и преимуществ между X и Wayland. Её написал Eric Griffith, при участии Daniel Stone, специально для ресурса phoronix. Работа собрана по кусочкам из презентаций Keith Packard, David Airlie, Kristian Høgsberg, из страниц про X11, X12, Wayland в вики и на freedesktop.org, из прямых интервью с разработчиками.

Оригинал выпущен под Creative Commons версия 3, с указанием авторства; перевод доступен на тех же условиях (с указанием на авторов оригинала, как мне кажется).

Недостатки X

Прежде всего автор думает, что преимущества Wayland лучше всего понятны через перспективу недостатков X11. Итак, начнём...

  1. Мы потратили последние десять лет на «исправление» X с помощью оборачивания его расширениями и плагинами. Однако, X имеет минимальную поддержку версионирования расширений.
    • Версионирование ведётся для одного клиента, а не для одного соединения с API расширения; если ваше приложение поддерживает одну версию расширения, а библиотеки — другую, вы не можете предсказать, какая версия расширения будет получена в итоге.
    • Мысленный эксперимент: Rekonq поддерживает Xinput 2.2, библиотеки KDE — Xinput 2.0, а плагин Flash — только базовый X11. Все они будут определять, какая версия подсистемы ввода поддерживается браузером Rekonq, и в результате будет отдана одна версия для работы со всем вводом... И это может быть не та версия, которая имеет всё необходимое.
    • Если вы счастливчик, вы получите минимальную поддерживаемую версию и приложение будет работать хорошо. Если вы не очень удачливый, вы получите максимальную версию и будете посылать бесполезные сообщения между клиентом и X.
  2. X имеет четыре подсистемы ввода: базовый протокол X11, Xinput 1.0, Xinput 2.0, Xinput 2.2. Xinput 1.0 канул в Лету, но оставшиеся три остаются взаимосвязанными. Daniel Stone описал это так: «Есть всего три человека, которые действительно понимают, как подсистемы ввода уживаются вместе... И я бы хотел не быть одним из них».
  3. Много лет назад у кого-то появилась идея «механизм, а не алгоритм». Фраза является отсылкой к тому, что X имеет свой уникальный API для рисования и собственную библиотеку вроде GTK+ или Qt. X определяет низкоуровневые понятия, такие как прямая линия, толстая прямая линия, дуга, окружность, неполноценные шрифты и другие элементы конструктора, бесполезные по отдельности. Примечание от Daniel: «Внешний вид толстых линий должен точно соответствовать спецификации, которая обязывает их выглядеть уродливо».
  4. X большой и тупой. Прежде чем мы (сообщество) начали выкидывать его компоненты и использовать обходные пути, X имел внутри почти полную ОС, включая свой сервер печати и свой бинарный транслятор для ELF, COFF и a.out.
  5. Композитинг и синхронизация окон. Разработчики научили X композитингу с помощью Composite Extension. Композитинг хорош для простых случаев, как то: рабочий стол, OpenGL. Но если вы захотите использовать hardware overlays (т.е видео), может случиться катастрофа. В том же браузере содержимое вкладки и окно flash-плагина обрабатываются отдельно и не синхронизируются, так что остаётся лишь скрестить пальцы в надежде. что разница во времени обработки не будет слишком большой. В результате при прокрутке страницы с играющим видео иногда возникают разрывы и артефакты.
  6. Шрифты. Разработчики пытались перенести шрифты под управление X-сервера с помощью расширения STSF, и предоставить клиентам достаточную информацию, чтобы те могли правильно определить расположение шрифтов на экране. Но количество информации, достаточной для выполнения данной задачи, превышало размер самих шрифтов. В итоге было решено предоставить клиентам полную свободу действий, избавившись от шрифтов на сервере.
  7. Протокол без состояний. Иными словами, X ничего не запоминает.
    • «Пожалуйста, создайте мне X.conf. Пожалуйста, используйте его для настройки.» Зачем?! Со временем это было исправлено: файл конфигурации используется для перезаписи параметров по умолчанию, а сами параметры по умолчанию подчищены и могут теперь определяться автоматически.
    • Многие имели проблемы с многомониторными конфигурациями в Linux, ну или хотя бы перенастраивали X после перезагрузки. Недостаток X в том, что он помнит эти конфигурации только после создания /etc/X11/xorg.conf.d/50-monitors.conf, который скорее всего придётся писать вручную.
    • Мы надеемся, что это было исправлено созданием libkscreen, обёртки над xrandr, которая наконец-то стала запоминать параметры мониторов, используя их уникальный EDID.
    • В течение длительного периода (а может быть и до сих пор) при подключении дополнительного монитора в Linux основной монитор имел композитинг, а дополнительный — нет. Это, возможно, исправлено в RandR1.4, но его автор не может найти убедительных доказательств.
  8. Бесполезная иерархия окон. В X каждое поле ввода и текстовая надпись имеют своё окно со своим родителем. Никто не знает, какую же функцию выполняет эта иерархия. Реальные библиотеки (т.е не основанные на компонентах протокола X11) уже давно выбросили весь этот мусор в окно.
  9. Отчасти придирка, отчасти разумное беспокойство... В X11 каждая из координат— 2-байтное число со знаком. То есть, на всех ваших дисплеях должно быть не более 32,768 пикселей. При 100dpi это даёт вам 8,3-метровый дисплей. Замечательно... Но вот факты для сравнения: Windows XP имеет 96 DPI, а мой телефон — 320+. Добавьте сюда растущие разрешения и несколько мониторов, и вы увидите, что проблема приближается очень даже быстро.
  10. Для X всё является окном, и разных типов окон с его точки зрения нет.
    • Скринсейвер — это окно, которое просит X расположить его поверх всех окон, сделать полноэкранным и отдать весь ввод.
    • Всплывающее окно просит X расположить его в заданной точке и отдать весь ввод.
    • Они конфликтуют: скринсейвер не будет активирован, пока показано всплывающее окно.
    • Наверняка ваши скринсейвер и скринлокер не прокинули хуки во все необходимые библиотеки, распознающие клавиши для управления медиа... Представьте, что вы слушали музыку, работая на ноутбуке, а затем закрыли крышку. Ноутбук уснул, скринсейвер стал активным окном. Как только вы откроете крышку, ноутбук проснётся и музыка загромыхает снова, так что снова закрыть крышку окажется проще, чем вбить проль, затем открыть плеер и поставить его на паузу либо выключить звук.
    • Разработчики пытались исправить проблему и сделали спецификацию нового расширения, которое в теории работало. Но когда его попытались реализовать, оказалось, что оно серьёзно ломает модель работы X-сервера. Так что проблема существовала 26 лет и продолжает существовать. Расслабьтесь и получайте удовольствие.
  11. «Но Eric, если X11 настолько плох, то почему бы не сделать X12 вместо нового протокола?». Ну, формально, это уже сделано. При сохранении его под знаменем X возникает практический недостаток: все, кто беспокоится о X, будут иметь право голоса в разработке следующей версии. С помощью названия «Wayland» этой проблемы можно избежать. Никого ничто не волнует. Это не связанный с X проект, разработчики могут творить с будущим дисплейным сервером всё, что душа пожелает, ну а те, кто беспокоится о X, могут пойти разрабатывать X12.

Лекарство от Wayland (пронумерованы попарно с недостатками X).

  1. Весь протокол версионирован. Каждый слушатель получает именно ту версию, которую он поддерживает, и ничего поверх этого. Никаких случайностей.
  2. Подсистема ввода в Wayland очень похожа на Xinput 2.2, за вычетом всего старья и отношения Master/Slave между источниками ввода. Слушатель получит одну виртуальную клавиатуру, одну виртуальную мышь и один невиртуальный сенсорный ввод. Кошмар под названием «мультитач» в конце концов упорядочен. Примечание от Daniel: как один из авторов мультитача в X, я считаю себя достаточно компетентным, чтобы назвать его кошмарным.
  3. У Wayland нет API для рисования, в обход которого можно было бы работать. Wayland ожидает заполнения клиентом буфера рисования, и его не волнует способ заполнения, если не считать контроля за попытками задеть чужие буфера.
  4. Wayland минималистичен, он не хранит внутри себя псевдо-ОС ради контроля вывода графики. Клиенты принимают на себя этот удар, что хорошо — им не придётся заботиться о сверхдолгом сопровождении обратной совместимости. Qt5 избавилось от модуля qt3support. X всё ещё сопровождает то, что было написано 26 лет назад. Примечание от Daniel: кроме того, вызовы к вейланду — не блокирующие, рисование всего рабочего стола не остановится из-за зависания или очень дорогой операции на стороне одного из клиентов: остановится только этот клиент.
  5. В вейланде — принудительный композитинг. Это не означает, что везде должны быть 3D-эффекты или изгибающиеся окна. Под композитингом мы подразумеваем отсутствие разрывов, необновлённых кусков и проблесков. Лозунг вейланда — «каждый кадр будет идеальным». Каждый пиксель прорисован как должно и расположен где должно, и появляется, когда клиент того потребует.
  6. Шрифты отданы клиентам.
  7. Многомониторные конфигурации и гибридная графика (Optimus) отданы клиентам, вейланду нужен только буфер с пикселями и информация о том, где его расположить.
  8. В вейланде есть два вида окон: окна верхнего уровня и подповерхности (в основном для проигрывания видео). Причём, в отличие от X, они синхронизируются. При прокрутке страницы с видео в браузере у вас не будет ни разрывов, ни артефактов.
  9. С точки зрения клиентов, вейланд не оперирует глобальными координатами, предпочитая систему отсчёта поверхности для рисования. Счётчик координат 31-битный, то есть каждая поверхность может иметь 2,147,483,648 пикселей как в ширину, так и в высоту.
  10. Для обеспечения дополнительной безопасности, ваш скринсейвер и скринлокер являются частью композитора. Кроме того, композитор распознает клавиши управления медиа, так что даже при заблокированном экране можно выключить звук.

Некоторые заблуждения в плане X и Wayland.

  1. «X — это юниксвейно». X обрабатывает печать, управление буферами для рисования, имел свой тулкит, обрабатывал шрифты, имел бинарный транслятор — и всё это помимо других задач.
  2. «В X есть сетевая прозрачность» — её нет. Базовый протокол X и DRI-1 имели сетевую прозрачность, но никто не использует ни то, ни другое. Shared-memory, DRI2 и DRI-3000 не имеют сетевой прозрачности и не работают по сети. В наше время X превратился в синхронный, плохо сделанный VNC. Если бы он был плохо сделанным асинхронным VNC, то может быть мы бы и заставили его работать. Но он не такой: XLib синхронная, а переход на XCB медленный, что делает передачу по сети настоящим кошмаром.
  3. «Разработчики Wayland наступают на те же грабли, что и X11, потому что не знают его» — неверно, потому что большинство разработчиков Wayland являются бывшими разработчиками X11.
  4. «Вейланд требует 3D.» — неверно, он требует только композитинга, так что есть даже бекенд на pixman для программной отрисовки.
  5. «Вейланд не умеет в удалённый доступ» — умеет, и должен справиться с этой задачей лучше чем X, отчасти из-за асинхронности протокола. Скорее всего Wayland станет высокопроизводительной версией VNC, и прототип уже есть. Причём мы ещё ни разу не давали идей по его улучшению, и скорее всего сможем сделать его лучше, если приложим усилия.
  6. «Вейланд нарушает обратную совместимость» — с тех пор как XWayland закончен и принят в основную ветку, у нас должна появиться почти совершенная обратная совместимость, потому что каждое приложение, использующее X, получает маленький X-сервер для дальнейшей работы с ним. Нам известно одно препятствие — трансформации окна, ведь приложение думает, что оно расположено в верхнем правом углу экрана, оттого, что клиентский X-сервер приведён к размерам клиентского окна.

Парочка характерных преимуществ Wayland

  1. «Каждый кадр будет идеальным». Каждый кадр будет представлен в правильном порядке (возможен сброс лишних кадров, но вы не получите кадр 199, затем 205, а затем 200 оттого, что сервер извлёк их в произвольном порядке. Каждый кадр имеет свой timestamp.)
  2. Минималистичный! Мы способствуем славному будущему Wayland путём уменьшения пространства для возможных ошибок.
  3. Бекенды, специфичные для оборудования. Думается, некоторые люди заметили появление бекенда Wayland, предназначенного для Rasberry Pi — он позволяет использовать все особенности этой платформы. Такой подход используется не везде, многие вещи не потребуют бекенда для конкретного оборудования, но неплохо бы иметь возможность сделать доработку, когда потребуется.

P.S. От переводчика: заметно, что в статье мало технических деталей или же ссылок, а лозунги я наоборот вырезал. К слову, о минималистичности: для вейланда уже есть композитор, способный отображать окна в 3d-пространстве на манер quake, но что-то я сомневаюсь в правильной обработке звука в таком 3d. Для игр есть OpenAL, который имеет 3d-координаты, соответствующие координатам OpenGL (синхронизация позиций источников звука и слушателя с позициями объектов и камеры производится программистом). Для вейланда нет ничего подобного OpenAL.

Если же кто-то имеет вопросы к авторам статьи — он может задать их на Phoronix.

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

★★★★

Проверено: maxcom ()
Последнее исправление: Aceler (всего исправлений: 16)

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

А сурфейсы там по волшебству появляются? То, что Wayland не специфицирует это API, это не значит, что там ничего нет. Каждый тулкит велосипедит своё.

Ну хватит уже, я скоро фейспальмами весь покроюсь.

Всё, кроме OpenGL — это то самое API для рисования в прямоугольники, которые затем сшивает композитор. Именно так работает композитный режим в Xorg. Только там ещё куча вызовов обрабатывается, которые в композитном режиме совсем не нужны и не будут вызваны, но требуются по спецификации X.

Хватит, демон, остановись.

Да. В Mir пошли ещё дальше — у них в Single Unix Specification отсутствует API вообще. Только тулкиты.

Остановись, говорю.

Парень,ты понимаешь, что ты просто тотально, полностью, абсолютно не знаком с матчастью? Настолько не знаком, что даже не знаешь, что такое Single Unix Specification. Уймись. Займись самообразованием. Не ходи тут с умным видом и не мешай дядькам обсудать взрослые темы. Если хочешь быть наравне: выучись и приходи. А пока у тебя такой уровень знаний, что содержимое SUS зависит от велений космонавта, а API для работы с сюрфейсами видеокарты зависит от тулкита, тебе просто нечего делать в этом обсуждении.

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

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

Ну и сделать её прозрачной по сети, оставив wayland тонким слоем абстракции над железом.

есть libsdl — вполне годится на роль такого тонкого слоя (быстра, умеет *кроссплатформенно* писать прямо в видеопамять, емнип умеет двигать текстуры в памяти, умеет opengl, из «сложностей» в апи — только двойная буферизация (что совершенно необходимо), емнип умеет держать очередь событий от мыши и клавиатуры)

есть к ней довесок в виде рендерилки ttf и вывода звука (или уже прямо это в ней, не помню)

если wayland — это такой тонкий слой, то я не понимаю, че такого сложного нужно было проектировать 5 лет и писать? есть же перед глазами готовый образец, да и код в libsdl под lgpl — в чем проблемы просто его взять?

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

Кстати, насчёт обсуждения в другом треде:

я это все видел только краем глаза, но там че-то вроде типа html было — и если не совру, оно интерпретировалось виндой, а не прогой

а компилятор ресурсов, если опять не вру, только превращал это в нечто, что можно было линковать к аппликухе

Виджеты от этого в винде никуда не деваются. Этот компилятор ресурсов просто генерирует бинарный конфиг, по которому потом может быть создано дерево виджетов. Такой прообраз xml-я.

А виджеты в винде реализованы в одной из стандартных dll-ок. Виджеты там — это иерархические окна, как в motif — на каждый виджет отдельное подокно. Окнам этим можно посылать сообщения и получать от них уведомления (или наоборот, посылать уведомления и получать сообщения, черт знает их терминологию), так взаимодействие с виджетами из программы и производилось.

Потом появились простенькие тулкиты с неким подобием ООП, где все эти кишки с отправкой сырых сообщений были завернуты в процедуры.

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

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

А пока у тебя такой уровень знаний, что содержимое SUS зависит от велений космонавта

Ты сам начал делать странные аллегории, а теперь их не понимаешь.

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

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

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

Ты сам начал делать странные аллегории, а теперь их не понимаешь.

Кто-то из нас плохо знает русский язык. Уверен, что не я.

В общем, за отмазку ссылка на «аллегорию» не катит.

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

Уж знаешь, лучше проблемы с общением, чем с умом. Неполиткорректно, зато честно. И рекурсивно. :D

Почему я, например, tailgunner-у никогда не пишу, что он не в теме предмета обсуждения? Да потому что во всех обсуждениях, в которых он принимает участие, он в теме. Зачастую, намного лучше меня.

Такшта задумайся, да.

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

Ну ты более в теме обсуждения, потому что я патчингом занимался достаточно давно, а ты, видимо, попозжее.

Так что если хочешь, можешь написать, как оно там изменилось с 2006-го года, я с удовольствием почитаю и не буду тебя перебивать.

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

Этот компилятор ресурсов просто генерирует бинарный конфиг, по которому потом может быть создано дерево виджетов. Такой прообраз xml-я.

А виджеты в винде реализованы в одной из стандартных dll-ок.

я так примерно себе это и представлял

а речь была о том, что эта схема, похоже, позволяет легко реализовать сетевую прозрачность — если предположить, что «бинарный конфиг» перекидывается по сети с хоста А, где исполняется прога, на хост В, и рендерится уже dll-кой хоста В, где его и видит юзер за монитором, подключенным к В

понятно, что эвенты (т.е. мышеклик например) нужно еще двигать по сети обратно с В на А (хотя правильно приготовленная такая система должна обрабатывать как можно больше эвентов прямо на хосте В)

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

А вот как новый гуй в винде сделан, не знаю.

я тоже не слежу, но знаю, что в винде сделали свой аналог xul, тоже на xml

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

А вот как новый гуй в винде сделан, не знаю.

щас кстати вспомнил ключевые слова avalon/xaml

википедия кстати пишет, что его фаерфокс умеет показывать :-)

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

Зачем? Закрывающиеся кабинки внутри одинаковые, что для М что для Ж.

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

Ты почему-то сосредоточился на одной задаче графического сервера — сетевой.

я тебе один (хотя и чуть из другой оперы) интересный момент расскажу:

There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team's data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.

Jeff Bezos, конечно, тут излишне эмоционален (по *особому* разрешению че-то можно делать через shared-memory model), но если подумать — он весьма близок к истине, и не важно, графическая система это или амазоновская платформа

весьма советую над его словами подумать, несмотря на их резкость

Anyone who doesn't do this will be fired.

а вот тут я с ним *полностью* согласен

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

бугага, это для тех кто стричь будет хомячков делается.

Это в бесплатной оси-то?

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

Во-первых. Если он «так и работает», нахрена нужен вейланд? Выпилите из иксового протокола все неиспользуемые вызовы и опкоды и замените подсистему обработки раскладок на более вменяемую. ВСЁ.

Вверху же написано, почему так не делают - NIH-синдром.

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

а речь была о том, что эта схема, похоже, позволяет легко реализовать сетевую прозрачность — если предположить, что «бинарный конфиг» перекидывается по сети с хоста А, где исполняется прога, на хост В, и рендерится уже dll-кой хоста В, где его и видит юзер за монитором, подключенным к В

Возможно, так и делается. Я не уверен, что RDP умеет форвардить именно сообщения на уровне семантики виджетов, а не команд отрисовки.

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

В принципе, ничего не мешает и в линуксе иметь такую же фичу. Для этого потребуется API для обсуждения клиентом и сервером имеющихся у них возможностей. «А есть ли у тебя компонент gtk_text_entry, версии не ниже 3.2, и какие опкоды назначены для общения с ней?»

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

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

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

Ну ты более в теме обсуждения, потому что я патчингом занимался достаточно давно, а ты, видимо, попозжее.

(устало) Патчингом чего ты занимался?

Aceler, ты ни на одно моё сообщение по существу не ответил. Неудобные или непонятные абзацы ты просто пропускаешь и начинаешь дальше гнуть в своем духе.

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

Возьмём вот эту твою реплику:

Всё, кроме OpenGL — это то самое API для рисования в прямоугольники, которые затем сшивает композитор. Именно так работает композитный режим в Xorg. Только там ещё куча вызовов обрабатывается, которые в композитном режиме совсем не нужны и не будут вызваны, но требуются по спецификации X.

Ты пишешь ерунду. Которая показывает, что об устройстве иксов ты не знаешь даже на уровне протокола ничего. Сделать тебе ликбез? Изволь: в X11 имеется три равноправных API для рисования: OGL, Xrender и рисующее API в Core Protocol. Равноправных. Все они рисуют на объектах типа drawables. Частный случай таких объектов: окна. Все они рисуют «прямоугольники» (окна!), «которые затем сшивает композитор». Да, и OGL тоже.

(Вру, кроме этих трех, есть еще расширения для вывода видео, но для упрощения изложения можно их не рассматривать.)

Композитному менеджеру не важно, каким из трех API нарисована картинка. Хоть всеми тремя сразу. Он получает damage-события от drawables, на которые подписан, и перерисовывает свой собственный drawable (рутовое окно). Это единственное, чем занят композитный менеджер. Механизмы рисования и механизм композитинга полностью развязаны и никак друг на друга влияния не оказывают.

Только там ещё куча вызовов обрабатывается, которые в композитном режиме совсем не нужны и не будут вызваны, но требуются по спецификации X.

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

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

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

(устало) Патчингом чего ты занимался?

KWin. Чтобы он работал в композитном режиме.

Вот насчёт аргумента, что в windows принудительная перерисовка окна никуда не делась и никому не мешает ты что ответил? Ничего.

А что тут можно ответить? Отвечаю: «причём тут вообще Windows?». То, что она никому не мешает, не имеет отношения к Wayland. Вот вообще никакого.

Все они рисуют «прямоугольники» (окна!), «которые затем сшивает композитор». Да, и OGL тоже.

OGL может рисовать также и без окон. Хотя да, слово «кроме» я там применил зря, складывается впечатление, что в окна OGL рисовать не может.

О чем тут говорить?

Не говори. Иди на Phoronix и говори с разработчиками. Я нигде не писал, что я разработчик Wayland и собираюсь что-то писать, не знаю, с чего ты это взял.

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

Судя по их ленте, автора pcmanfm просто сделал «на пробу» фронт-енд к libfm на Qt, получился эдакий pcmanfm-qt, про переписывания всего lxde на Qt у них в новостях не видел...

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

LXDE перешла на Qt из-за тех же самых опасений.

гм, круто я что-то пропустил... нужно будет им тогда mount-tray подарить :-D

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

про переписывания всего lxde на Qt у них в новостях не видел...

$ wget http://lxde.git.sourceforge.net/git/gitweb-index.cgi -qO - | egrep -io '[-a-z]+qt' | sort -u
lxde-common-qt
lximage-qt
lxinput-qt
lxpanel-qt
lxrandr-qt
obconf-qt
geekless ★★
()
Ответ на: комментарий от www_linux_org_ru

скорее всего, ложь

Вокруг везде ложь, нужно доверять интуиции :}

Deleted
()
Ответ на: комментарий от I-Love-Microsoft

Обязательно держи нас в курсе.

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

Не знаю насчёт принт-сервера (хотя подозреваю, что альтернативы просто были на голову выше), но иксовые шрифты — ад.

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

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

По-твоему, лучше поддерживать принт-сервер при том, что в cups заведомо лучшая поддержка практически всех принтеров и встроенный не будет работать в 99% случаев? Ну а шрифты — с клиентскими всё прекрасно работает.

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

Вот накой хрен(это овощ такой) в системе управления окнами надо все это счастье?

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

мультитач(3+ пальцев)

мультитач доступен с x.org 7.5. есть соответствующее железо? ставь федору или убунту, там вроде из коробки все работает году так с 2010.

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

по-моему я четко написал, что по-моему.
встроенная работала и не в 1%, а намного больше. лично настраивал и использовал. текущая ситуация, когда этого нельзя сделать, конечно же, гораздо лучше.

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

Q: How does Xprt find fonts ? A: Lookup-rule for Xprt's PostScript DDX to find fonts: Printer-builtin fonts (defined by the fonts/-dir in the model-config) PostScript fonts (will be downloaded via generated print job) GFX-fonts build from X11 scaleable fonts GFX-fonts build from X11 bitmap fonts

Ну, это однозначно подлежит закапыванию. PS-шрифтов не так уж много. X11 scaleable/bitmap fonts — это вещь, которую НЕЛЬЗЯ использовать в серьёзном международном продукте по очевидным причинам (напоминаю: сейчас не 1998 год и юникод не ограничивается кириллицей + латинницей). Если лично ты хочешь поддерживать Xprt — это твоё право, тут опенсорс, но я прекрасно понимаю, почему все вменяемые девелоперы бросили это говно мамонта.

TTF-шрифты поддерживаются либо через core x-протокол (ограниченный 2 байтами на символ), либо через закопанный за дело xfs (server-side шрифты никогда не работали).

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

Мнение свитера о программирование очень ценно. Прошу не пропадать из виду.

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

Ключевое тут то, что библиотека виджета гарантировано присутствует на дисплее.

это да

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

нет, я прав в том, что акцентирую внимание на связь этой фичи именно с конфигом

разница «бинарного конфига» с бинарным сериализованным сообщением CreateWindow лежит не в принципиальной плоскости, а в плоскости удобства разработки, валидации и верификации

т.е. в *принципе*, я могу обозвать твое сообщение CreateWindow маленьким бинарным конфигом, и ты хрен меня оспоришь — но смысл бинарного конфига, конечно, совсем не в этом

смысл вот в чем:

1. на практике окна (даже формочки) весьма статичны, т.е. вместо цепочки CreateWindow гораздо удобнее конфиг

2. нестатичность форм обычно лежит во вполне определенной плоскости, которую можно и нужно учесть в бинарном конфиге:

Вести лог:  [х]
Файл лога:  [ /home/user/my_log.log ]

(т.е. если убрать флажок, пропадает целая строчка, а если флажок поставить, то она появляется)

3. контекстные меню тоже весьма статичны, появление в них динамических пунктов, конечно, нужно, но сами эти пункты занимают небольшой процент об общего количества (например «Search google for „тот текст, что был выделен в момент вызова меню”»)

4. бинарный конфиг можно редактировать вне приложения — можно заменить:

Description1: value1
Description2: value2
Description3: value3

на

Description1 Description2 Description3
   value1       value2       value3
без перекомпиляции аппликухи и даже прямо на графическом сервере (переписывающий графический сервер, да!)

5. бинарный конфиг удобно переводить

6. бинарный конфиг можно валидировать/верифицировать, т.е. скажем не пропустить

<table columns=2 rows=2><td>a</td><td>b</td><td>c</td><td>c</td><td>бугага</td></table>

на этапе сборки/пакетирования аппликухи (естественно, синтаксис html/xml — это говно; я использую его только для иллюстрации идеи)

и даже если я чего-то забыл — популяность html это именно популярность конфига (хотя и не бинарного); то, что сейчас к хтмл прикрутили всякие операции с DOM еще не служит доказательством, что эти операции в правильно спроектированном хтмл часто нужны, а скорее служит доказательством того, что в хтмл нет много чего

з.ы. но вот можно ли сказать «CreateWindow не нужно»? я не уверен

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

// Ужос який.

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

А построение гуя по конфигу — это примитивный рекурсивный обход дерева с дерганием конструкторов на каждом узле. Абсолютно пофиг, кто этим будет заниматься, и в каком формате это дерево хранится.

А «формочки» я мышкой в glade натыкиваю, так что «пропустить тэг» для меня не грозит. Собственно, для любого разработчика xml-ный glade и есть такой бинарный, нечитаемый конфиг.

валидировать

Тут уместно ответить шаблонной фразой: «Если ты не знаешь, как программно валидировать xml, у меня для тебя плохие новости».

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

Виджеты? В сервер? Да вы упоролись наглухо.

ага, конечно, иметь 100500 разных реализаций поля текстовго ввода, без возможности заюзать плюсы поля текстового ввода Qt из программы в gtk и наоборот — это trueЪ

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

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

иметь 100500 разных реализаций поля текстовго ввода, без возможности заюзать плюсы поля текстового ввода Qt из программы в gtk и наоборот — это trueЪ

Ты правда думаешь, что всем будет достаточно встроенного в сервер набора виджетов? Нет? Тогда ты, наверное, дашь возможность создавать свои наборы виджетов (привет, NeWS)? И у тебя внезапно те же проблемы взаимодействия между разными тулкитами.

В общем, facepalm.mkv (4.7G).

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

А построение гуя по конфигу — это примитивный рекурсивный обход дерева с дерганием конструкторов на каждом узле.

не совсем, а может даже совсем не

у вас в gtk есть layout-ы? ну и подумай о html table — настоящей html table, а не той пародии че я тебе нарисовал

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

нет, не пофиг

локальная обработка (части) эвентов от виджетов дает возможность не ждать тормозного ответа из сети и исключить гонки — это одна из киллер-фич html

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

Ты правда думаешь, что всем будет достаточно встроенного в сервер набора виджетов?

*почти* достаточно — хтмл тому _*практическое*_ доказательство

Тогда ты, наверное, дашь возможность создавать свои наборы виджетов

дам

(привет, NeWS)

в чем проблемы NeWS?

и почему ты думаешь, что это будет именно так?

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

Мне показалось, что ты поддерживаешь эту идею, раз не предложил закопать ее на старте.

Я в принципе допускаю, что в _каких-то_ случаях проведение основной линии API подальше от OGL и поближе к html может иметь смысл.

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

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

И у тебя внезапно те же проблемы взаимодействия между разными тулкитами.

и как же так html ободится без этих Ужасных Страшных Проблем? колдовством, не иначе

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

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

браузер — это жирное тормозное говно, юзающее язык с синтаксисом, не подходящим ни для человека, ни для робота

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

у вас в gtk есть layout-ы? ну и подумай о html table — настоящей html table, а не той пародии че я тебе нарисовал

Есть. И чего мне о ней думать? В gtk вот она.

локальная обработка (части) эвентов от виджетов дает возможность не ждать тормозного ответа из сети и исключить гонки — это одна из киллер-фич html

...и требует тьюринг-полного языка, доступного приложению со стороны дисплея. Это еще одна, гм, «киллер-фича» интерфейсов на html.

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

всем будет достаточно встроенного в сервер набора виджетов?

*почти* достаточно — хтмл тому _*практическое*_ доказательство

Ы. Епт. Какой нафиг HTML? Это чертов клубок из DOM и JavaScript. И его проблемы обратной совместимости просто ужасающи на фоне иксов.

Тогда ты, наверное, дашь возможность создавать свои наборы виджетов

дам

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

в чем проблемы NeWS?

Она умерла до выхода в широкое использование, так что точного списка ее проблем мы никогда не узнаем.

и почему ты думаешь, что это будет именно так?

Потому что я знаю историю своего ремесла.

и как же так html ободится без этих Ужасных Страшных Проблем?

Что такое, разные наборы виджетов (YUI, jQuery, whaever) уже совместимы?

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

Вопрос построения гуя из конфига к вопросу о том, как этот гуй работает, полностью перпендикулярен.

нет, не перпендикулярен

Меня интересует именно второй, потому что он сложный нетривиальный.

меня тоже

И тулкиты у нас косоватые и кривоватые.

и это тоже интересно

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

и как же так html ободится без этих Ужасных Страшных Проблем? колдовством, не иначе

Колдовство называется jquery, extjs и тэпэ.

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

Какой нафиг HTML? Это чертов клубок из DOM и JavaScript.

«чертов клубок» из него делают ненормальные, подверженные моде на аякс, а у нормальных людей все работает без DOM и JavaScript

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

и требует тьюринг-полного языка, доступного приложению со стороны дисплея.

1. не всегда требует — куча интернета работает без него

2. и в чем проблемы, если требует?

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

у нормальных людей все работает без DOM и JavaScript

Чем дальше, тем чудесатее. Ты утверждаешь, что стандартных виджетов HTML (пусть даже HTML5) хотя бы почти хватит всем?

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

Чем дальше, тем чудесатее. Ты утверждаешь, что стандартных виджетов HTML (пусть даже HTML5) хотя бы почти хватит всем?

я вынужден тебе сказать, что «знать историю своего ремесла» недостаточно — для дискуссии необходимо так же читать то, что тебе пишет собеседник, и понимать написанное

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

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