Официально стартовал проект, альтернативный XFree86.org

э. irsi, кто тебе сказал, что "в иксах каждая программа считает что она работает через сеть"? ты на xlib писал чего-нибудь? =) там все те же gc и dpy всякие, что и в gdi твоем. а про прынтер - сделать hplj4_drv.o будет не так и сложно =/ короче либо ты чего-то не понимаешь в Хах, либо, как собака, сказать не можешь =)

Irsi: хотя MacOS X и гоняет потомков DSP (правда использует PDF вместо PS), но не по сети; по сети пока не умеет, не доросла до X ;)

2anonymous (*) (2003-04-15 16:07:48.847678): да ну??? ну тогда несколько вопросов на засыпку:
1. Что такое PDF, DPS, EPS и PS и чем они отличаются друг от друга...:)
2. Не умеет гришь? Ну возможно... а это что - http://www.apple.com/remotedesktop/ простите? Хотя если честно я не знаю как оно там внутри работает, может конечно и битмапы гоняет, но имхо врятли это так...

Irsi: ну прям экзамен какой-то Вкратце 1) DPS - это когда программа генерит PS и не заботясь об устройстве вывода посылает в GDI, который отображает на экране, принтере и где угодно, в зависимости от характеристик устройства. PS Адобовский язык описания страниц, EPS - его одностраничный вариант (encapsulated), используется чаще для картинок (задан размер, BoundingBox, кажись), которые удобно встраивать в LaTex. PDF (расшифровывать?) Адобовский стандарт на основе PS (со сжатием, шифрованием...) B MacOS X (кажись с ягуара) он используется вместо PS для GDI). 2) Обратил внимание: Apple Remote Desktop 10-Client Edition $299 Apple Remote Desktop Unlimited-Client Edition $499 - это за отдельную плату, то есть не в стандартной поставке, (такое есть за отдельную плату и у M$ RDP, кажись, и Citrix), наверняка отдельный протокол.

2anonymous (*) (2003-04-15 16:38:06.658838): ага... а то у меня сложилось впечатление что ты считаешь PS & PDF абсолютно разными и никак не связаными между собой вещами, не обижайся, ок? Вижу что я ашипся...;)
Вообщем я это к тому что что оно там гоняет, не важно, главное то что это нечто, базирующиеся на PS - универсальном языке для описания двумерных графических данных... Ибо насколько я помню мы ведем речь о принципе построения, а не о конкретной реализации...

На счет ARD - ну да, отдельно поставляется, ну да - Apple решила что большинству юзверей это фича не нужна (абсолютно законно имхо решила), а кому нужна - денег заплатят (и к слову - дешево продает). Насколько я понимаю "костяк" в MacOS X обязан быть изначально, в этот пакет входит собственно "драйвер" сетевого терминала для эплового гди и эмулятор этого терминала...:)

Естественно никто и не думал обижаться ;) DPS принцип построения оконных систем конечно имеет огромный потенциал. Интересно, существуют ли DPS системы, которые сочетают в себе DPS/GDI и полную сетевую прозрачность, как в X?

Интересная (правда вышедшая давно) статья о MacOS X Jaguar http://itc.ua/article.phtml?ID=11170

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

2anonymous (*) (2003-04-15 18:14:31.047397): насколько я помню вроде GNUStep пытался сделать гнутую версию DPS, работающую поверх иксов... Но имхо сам по себе подход неправилен - не надо это делать поверх иксов...:)
Выкидывать ничего не надо - надо сесть и сделать с нуля систему базирующуюся на более современных принципах, ведь когда делались иксы многих вещей как таковых еще просто не существовало или они были в зародеше, например DTP... С другой стороны - можно и нужно обеспечить ограниченную совместимость новой системы с иксами. Ну скажите что мешает новой графической подсистеме поддерживать например кроме видеокарточек nVidia, ATI, Matrox, VESA еще и "виртуальные видеокарточки" X-server, RDP, ICA, VNC? :)
Т.е. имхо цепочка упрощенно должна выглядить так:
1. Пользовательсткая программа передает GDI (посредством того же DPS например) некий набор графических примитивов.
2. GDI выступает в роли менеджера ресурсов, передает эти примитивы некому своему драйверу, который транслирует эти вызовы на язык графических примитивов конкретного устройства - видеокарточки, принтера, удаленного терминала и т.д.
3. Происходит передача этих примитивов конкретного устройства к устройству, через AGP, PCI, USB, LPT, TCP/IP и т.д. :)

P.S. И первое что надо сделать это фонт-сервер, заточенный под передачу контурных шрифтов типа ps/ttf...;)

2ALutsenko:
>...и никаких альтернатив
ОК, чем тогда XFree86 не набор альтернатив? Чего конкретно вам в нём
не хватает?
Если действительно чего-то не хватает, то ИМХО нужно его дорабатывать,
а не упрощать

   ограниченную  совместимость  новой  системы  с  иксами. Ну скажите что
   мешает   новой  графической  подсистеме  поддерживать  например  кроме
   видеокарточек   nVidia,   ATI,   Matrox,   VESA   еще  и  "виртуальные
   видеокарточки" X-server, RDP, ICA, VNC? :)
Для XF4 есть драйвер-расширение, который делает доступным текущий
десктоп *также и* по протоколу vnc (звать его x4vnc что-ли) - то есть сбылась
давняя мечта - можно смотреть фильмы и игры используя аппаратный
ускоритель и в тоже время подключаться к этому же декстопу удаленно
и им управлять. Искать на sourceforge.

2hvv: замечательно что это есть под иксы, вся проблема в том что сами иксы не устраивают по ряду параметров, по каким - см. выше.

А DPS - весьма старый проект в XFree, и он уже худо-бедно есть, и развивается.
Т.е. по большому счёту, иксы не устраивают потому, что они иксы? :)

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

API для печати документов - очень даже единый. PostScript зовётся.

Таким, как ты юзерам игровой приставки выше крыши хватит. И никого из серьёзных разработчиков вы, лохи позорные, не интересуете.

>Блин, сколько клинических дебилов развелось, не понимающих слова >IPC, и размахивающих дебильной идеологией "персонального компутера". >Может, пора уже отстрел начинать, в целях улучшения генофонда >человечества?
Ты это с кем разговаривал сейчас?

>API для печати документов - очень даже единый. PostScript зовётся.
Ага, ps - задумка хорошая, только реализация плохая.
API для рисования должен быть один как для вывода на принтер, так и на монитор и.т.п.

>Таким, как ты юзерам игровой приставки выше крыши хватит. И никого >из серьёзных разработчиков вы, лохи позорные, не интересуете.
Да, точно, есть такая категория разработчиков в себе, которых только они сами и интересуют. Разрабатывают себе помаленьку, не для лохов конечно. Только зарабатывают обычно другие, которые пишут меннно для лохов.
8-))))))

именно для лохов. (привет MS)

http://www.stud.uni-karlsruhe.de/~unk6/transluxent/
http://www.stud.uni-karlsruhe.de/~unk6/transluxent/tw4.jpg

Как отстреливать??? А биореактор чем наполнять??

Вырезка с xwin.org:
xwin.org is a forum for community participation in X, not a development project. The X development community needs to work together to form a government. The hope is that community governance will encourage rapid advances in the X window system.

Из чего вовсе не следует что создан новый проект(not a development project), а создается некое подобие комитета по переработке X-ов.

Не думаю что господа будут отказываться от распределенности X-ов (если не прав - укажите явно УРЛЬ на их сервере где об этом сказано).
Отказываться от текущей реализации тоже полный маразм (ибо помимо Linux'а есть еще 2 десятка Unix'ов, и переписывать все ради кучки дятлов не будут).

На мой взгляд главная проблема действительно в самом протоколе (ну не было в нем много чего заложено.), и надеюсь что умудрятся сохранить совместимость сверху-вниз. А xfree86 особенно не виноват, кидайте камни в адрес x.org. xfree86 не может сильно плясать от X11.

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

1. Проработать новый API (желательно сохранив, где это возможно совместимость с X11). Уверен что на 99% это возможно (не вижу в этом никаких проблем, т.к. останется значительная часть по обслуживанию оконной системы{если кто забыл - X-ы не только точки рисовать могут. Точки можно и через fb рисовать, а вот поддержку окон в ядре ОС делать .... хреновато... Там где обычно X-ы вылетали, будет ядро}, а расширятся только функции перерисовки областей). Можно например оставить текущий функционал, и добавить функции для вывода в backbuffer сервера, и.т.п.
2. Сделать x-либы с связью с X-cервером как через сокет, так и через shared memory.
3. Переписать X-либы с использованием нового API.

ЗЫ: кто-то заикался насчет скорости ?
Для работы с анимационной графикой ГЛЫБОКО убежден что через X-ы это невозможно:
1. Т.к. X-сервер - отдельный процесс - то каждый раз, когда вы ему говорите - отрисуй это, ОС переключает контекст, а это происходит по таймеру (т.е. каждые 20 миллисекунд, за исключением случая, когда планировщик задач использует прерывания, которых может и не быть в нужный момент...). К тому-же переключение контекста ОЧЕНЬ накладная процедура, и сокет тут невиноват.
И правильно идут Linux'оиды создавая framebuffer.
Вот что было бы полезно - это добавить функции для вывода напрямую (аля DirectX), но с единственным отличием: Если либа видит что мы работаем с локальными X-ами - дергаем frame buffer (или любую другую имплементацию), а если с удаленными - рисуем на удаленном (если я запускаю программу с другой машины - я предпочту получить медленно перерисовывающуюся картинку, чем полное отсутствие таковой.

Все, фонтан иссяк. Спасибо всем за внимание :-)

2 webmaster: сделайте хоть preview (перед постом), а то во как получатся....

Вырезка с xwin.org:
xwin.org is a forum for community participation in X, not a development project. The X development community needs to work together to form a government. The hope is that community governance will encourage rapid advances in the X window system.

Из чего вовсе не следует что создан новый проект(not a development project), а создается некое подобие комитета по переработке X-ов.

Не думаю что господа будут отказываться от распределенности X-ов (если не прав - укажите явно УРЛЬ на их сервере где об этом сказано).
Отказываться от текущей реализации тоже полный маразм (ибо помимо Linux'а есть еще 2 десятка Unix'ов, и переписывать все ради кучки дятлов не будут).

На мой взгляд главная проблема действительно в самом протоколе (ну не было в нем много чего заложено.), и надеюсь что умудрятся сохранить совместимость сверху-вниз. А xfree86 особенно не виноват, кидайте камни в адрес x.org. xfree86 не может сильно плясать от X11.

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

1. Проработать новый API (желательно сохранив, где это возможно совместимость с X11). Уверен что на 99% это возможно (не вижу в этом никаких проблем, т.к. останется значительная часть по обслуживанию оконной системы{если кто забыл - X-ы не только точки рисовать могут. Точки можно и через fb рисовать, а вот поддержку окон в ядре ОС делать .... хреновато... Там где обычно X-ы вылетали, будет ядро}, а расширятся только функции перерисовки областей). Можно например оставить текущий функционал, и добавить функции для вывода в backbuffer сервера, и.т.п.
2. Сделать x-либы с связью с X-cервером как через сокет, так и через shared memory.
3. Переписать X-либы с использованием нового API.

ЗЫ: кто-то заикался насчет скорости ?
Для работы с анимационной графикой ГЛЫБОКО убежден что через X-ы это невозможно:
1. Т.к. X-сервер - отдельный процесс - то каждый раз, когда вы ему говорите - отрисуй это, ОС переключает контекст, а это происходит по таймеру (т.е. каждые 20 миллисекунд, за исключением случая, когда планировщик задач использует прерывания, которых может и не быть в нужный момент...). К тому-же переключение контекста ОЧЕНЬ накладная процедура, и сокет тут невиноват.
И правильно идут Linux'оиды создавая framebuffer.
Вот что было бы полезно - это добавить функции для вывода напрямую (аля DirectX), но с единственным отличием: Если либа видит что мы работаем с локальными X-ами - дергаем frame buffer (или любую другую имплементацию), а если с удаленными - рисуем на удаленном (если я запускаю программу с другой машины - я предпочту получить медленно перерисовывающуюся картинку, чем полное отсутствие таковой.

Все, фонтан иссяк. Спасибо всем за внимание :-)

Так, опять эти уродские мелкомягкие сказочки. Как это меня достало...

МОНИТОР и ПРИНТЕР - АБСОЛЮТНО разные девайсы. У них нет НИЧЕГО ОБЩЕГО. И только пидерасты печатают на принтер тем же API, каким рисуют на мониторе (GDI, к примеру), вот и качество печати у них пидерастическое. Всех их надо убить.

Как чем? Трупами!

Ты и без всякой пены - дятел. Полный. Про DGA ни хера не знаешь. И про GLX... Всему этому лет не намного меньше, чем X11.

2Antichrist: вообще-то идею GDI мелкомягкие сперли у яблочников... Что на маках дерьмовое качество печати? Ну-ну... :)

Ещё как дерьмовое. Даже оптического алиасинга нет...

2Antichrist:
>...БлаБлаБла.... Про DGA ни хера не знаешь. И про GLX... Всему этому лет не намного меньше, чем X11.

И из какой строчки моей писанины это следует ?
Про DGA как ни странно знаю (ковырял чужой код), под GLX сам писал.

Если читал бы повнимательнее - узрел бы главную проблему DGA(что такого не существует - я не писал, я только утверждаю что это надо переработать).
Дублирую:
========
X-сервер - отдельный процесс - то каждый раз, когда вы ему говорите - отрисуй это, ОС переключает контекст, а это происходит по таймеру (т.е. каждые 20 миллисекунд, за исключением случая, когда планировщик задач использует прерывания, которых может и не быть в нужный момент...)
========
Упрощаю - передача большого кол-ва данных через отдельный процесс - ГОРАЗДО БОЛЕЕ НАКЛАДНАЯ ОПЕРАЦИЯ чем работа напрямую с ядром(накладная в плане непредсказуемых задержек, а не ЦПУ.

А если не рубишь в чем разница между взаимодействием MyAPP<=>XSERVER_APP<=>Kernel и MyAPP<=>Kernel - так хоть почитай, или как выражаются на энтом форуме - в сад.

RTFM, google, www.kernel.org, LDP тебе помогут (надеюсь...)