[не мое]Мысли вслух о протоколе X

> Нет. Прочитай внимательно - там описываются, как увеличивается количество костылей: разрабы (КДЕ в данном случае) не понимают, как функционируют иксы, и добавляют левый костыль (D-Bus).

А вот я это костылем не считаю, и даже более, сам бы поступил аналогично. Уведомлениями должно заведовать определенное приложение (это или «панелька с систреем», или всплывающие облачка на половину экрана для всяких телевизионных систем, или вообще что-то вроде сислога), но до него надо как-то достучаться. Дбас в данном случае - это стандарт, пропихиваемый именно для коммуникации между приложениями. Ну так и в чем проблема? Все правильно сделали. Не на том хосте будут вылазить? А вдруг я хочу вообще по смс эти сообщения получать и дабы отправлялка была именно на сервере приложений? А если надо на том, где само окошко, то некий session manager (а не просто переменная DISPLAY) должен редиректить запросы не только для иксов, но и для уведомлений, звука, принтеров и прочего безобразия.

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

Этим занимаются драйвера. А рисованием окошек (тем самым разделением 1 большого битмапа на множество мелких) они не занимаются.

Что иксы занимаются обработкой ввода (и устрйств ввода), ты не знаешь?

В курсе. Хотел было написать «разделением ввода/вывода», но тут ты опять придерешься к формулировке, так и до обработчиков прерываний можно дойти. Пусть будет «разделением пользовательских интерфейсов», хотя и это не совсем верно.

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

Этим занимаются драйвера.

Ну специально же написал «нескольких видях».

> Поправь (только все, а не Qt $LATEST.$LATEST и Gtk3). Потом обнови тулкиты на долгоживущих системах.

А зачем? Если уж можно поставить замену иксам, то уж всяко и обновление для Qt $LATEST.$LATEST

> Ну специально же написал «нескольких видях».

....и?

<> Поправь (только все, а не Qt $LATEST.$LATEST и Gtk3). Потом обнови тулкиты на долгоживущих системах.

А зачем? Если уж можно поставить замену иксам, то уж всяко и обновление для Qt $LATEST.$LATEST

Ты вообще понимаешь, что новые иксы и новый тулкит ставятся на разные машины?

Ну специально же написал «нескольких видях».

....и?

И без толку.

>Это просто «удобства» текущей реализации клиент-серверной архитектуры.

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

А реализации получше нет, об этом речь и идет.

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

ЗЫ У меня после прочтения возникло желание перемыть кости инноваторам из kde team.

> Ты вообще понимаешь, что новые иксы и новый тулкит ставятся на разные машины?

Если у нас есть машина, которую надо переправить под новые иксы, то совершенно не важно, где эти иксы установлены. Править, править и править.

И без толку.

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

А еще есть пачка клиентов (часики, калькулятеры, панельки, браузеры, порносмотрелки), которым нужно куда-то отображаться. Куда они сами не знают - этим занимается xlib/xcb/собственный быдлокод.

Иксы берут первое и делят между вторым. Или наоборот, второе мультиплексируют и размазывают по первому. Суть одна. Что еще не так?

> У меня после прочтения возникло желание перемыть кости инноваторам из kde team.

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

Да, соседний тред (http://www.linux.org.ru/forum/talks/5000286/) про офис - это не просто фантазии, а одна из идей, связанных с написанием тулкита

>звука

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

> Уже который раз за тред упоминаю FreeNX

Ты большей частью упоминаешь ее не к месту. Сжатие изображений с потерями может быть недопустима, например, для графических приложений по обработке изображений, предпечатной обработке и т.п. И FreeNX здесь занимает узкую нишу удаленного доступа к рабочему столу. И кстати, сравнивай скорость не с ssh -X, а с ssh -CX как минимум.

После разрыва соединения сессию можно возобновить.

Возможно, это единственное дельное его свойство.

> Если у нас есть машина, которую надо переправить под новые иксы, то совершенно не важно, где эти иксы установлены.

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

Какая прелесть.

Иксы берут первое и делят между вторым. Или наоборот, второе мультиплексируют и размазывают по первому. Суть одна. Что еще не так?

Всё так, ты ухватил самую суть. Более того, ты двумя предложениями описал вообще все современные графические системы, от GDI+ до Quartz. Мы все гордимся тобой.

>Запусти Opera 10.5x или links -g - и пойми, что графика в иксах не тормозная.

Простите, что разрушаю вашу идиллию, но запустите ту же оперу под win и убедитесь что отрисовка средствами nix/x11 затратнее в разы. Разрешаю посетовать на кривые драйвера

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

В статье есть ссылка на рассылку.

Плюсую ко всему посту. Отличная идея.

> Простите, что разрушаю вашу идиллию, но запустите ту же оперу под win и убедитесь что отрисовка средствами nix/x11 затратнее в разы. Разрешаю посетовать на кривые драйвера

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

> В статье есть ссылка на рассылку.

и ты опять про dbus? или еще про что-то?

> Плюсую ко всему посту. Отличная идея.

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

> Сжатие изображений с потерями может

Быть отключено (:

> Быть отключено (:

Так отключай и сравнивай. С ssh -CX. Разрешаю отписаться о результатах на ЛОРе

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

Это просто супер - хочу такой тулкит. ;)

Еще интересно посмотреть на путь Java Swing - на создание мегатулкита совместимого по Look and Feel одновременно с тремя средами Windows XP, Mac OSX, Gtk и еще несколько своих, ни с чем не совместимых LookAndFeel. Все в соответствии с девизом «Дайте мне canvas и я нарисую любой Look and Feel».

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

Процессоры стали двух/четырех ядерными. Ожидается появление многоядерных процессоров.

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

В видеопамяти обязательно должен быть альфа канал. А затем отдельные области видеопамяти могут при помощи отдельной схемы выводится на мониторы. Примерно так: области видеопамяти процессов -> области видеопамяти мониторов -> мониторы.

> Это просто супер - хочу такой тулкит. ;)

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

Вообще, пока я рассматривал исторические решения по созданию гуи, то пришел к 2 выводам:

1. основных концепций (отделить область, нажать на нее, подвигать ее) всего несколько штук

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

Еще интересно посмотреть на путь Java Swing - на создание мегатулкита совместимого по Look and Feel одновременно с тремя средами Windows XP, Mac OSX, Gtk и еще несколько своих, ни с чем не совместимых LookAndFeel. Все в соответствии с девизом «Дайте мне canvas и я нарисую любой Look and Feel».

1. ты пропустил мегасрач между белкой и нодашей, где они изобретали комбобокс

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

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

http://softwaremaniacs.org/blog/2009/11/30/gotta-rewrite-everything/ - это правда не про десктопы, но...

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

это уже есть и называется NUMA: http://en.wikipedia.org/wiki/Non-Uniform_Memory_Access, правда там без видяшек.

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

Это и будут иксы.

Примерно так: области видеопамяти процессов -> области видеопамяти мониторов -> мониторы.

А это оконный менеджер?

Шума много, а по ссылке http://www.x.org/wiki/Development/X12 не особо много проблем. Да дизайн может чуть и кривоват, но основная проблема в том, что мало кто понимает как оно работает и городят костыли.

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

Это и будут иксы.

Да, что-то навроде.

Примерно так: области видеопамяти процессов -> области видеопамяти мониторов -> мониторы.

А это оконный менеджер?

Да.

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

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

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

>и ты опять про dbus?

Ага, но приступ праведного гнева уже прошел, да и традиционную реализацию не выкидывают пока.