Боюсь, Z Window System будет уже тупиковым вариантом.

Не бойся... ;) Лиха беда началом. Пусть автор сделает результат, который можно будет пощупать, тогда уже посмотрим и выскажемся. А буквы после Z можно какие нибудь другие использовать - зачем же ограничивать себя латинским алфавитом, когда unicode "на дворе" :)

>решение - Y Window System

толку от этого >решения

покажите мне >НЕДОСТАТКИ X-ов...

покажите мне >НЕДОСТАТКИ X-ов...

Буза, ты мудак. Даже виндовый GDI по многим параметрам делает иксы при работе с одним пользователем. Или люди с фреймбуфером от недостатка острых ощущений мудохаются?

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

не компиляется :-(

>покажите мне >НЕДОСТАТКИ X-ов...

* Slow – High latency – Visible redraw – However, drawing operation throughput is high ² Too complex – Difficult to compile and install – Difficult to learn – Difficult to maintain and extend * No standard toolkit – Plethora of incompatible and inconsistent toolkits (Xaw, Motif, GTK+, Qt, FLTK, Tcl/Tk, . . . ) – Difficult to use applications – Internationalisation and accessibility nearly impossible * Poor understanding of fonts – Originally only bitmap fonts supported – Outline font support badly implemented – No font anti-aliasing (modern clients render the text themselves) – Font specifications are unnecessarily complicated, e.g. -adobe-helvetica-medium-r-normal--12-*-*-*-*-*-iso8859-15 * Overly complex colour model ² Poor when compared with other platforms’ windowing systems

>покажите мне >НЕДОСТАТКИ X-ов...

* Slow
- High latency
- Visible redraw
- However, drawing operation throughput is high
² Too complex
- Difficult to compile and install
- Difficult to learn
- Difficult to maintain and extend
* No standard toolkit
- Plethora of incompatible and inconsistent toolkits (Xaw, Motif, GTK+, Qt, FLTK, Tcl/Tk, . . . )
- Difficult to use applications
- Internationalisation and accessibility nearly impossible
* Poor understanding of fonts
- Originally only bitmap fonts supported
- Outline font support badly implemented
- No font anti-aliasing (modern clients render the text themselves)
- Font specifications are unnecessarily complicated, e.g. -adobe-helvetica-medium-r-normal--12-*-*-*-*-*-iso8859-15
* Overly complex colour model
² Poor when compared with other platforms & windowing systems

Наконец-то хоть кто-то бревно в глазу X-ов увидел...

>- Difficult to compile and install
Интересно, а у кого-нить получалось компилировать виндоуз?

- Font specifications are unnecessarily complicated, e.g. -adobe-helvetica-medium-r-normal--12-*-*-*-*-*-iso8859-15

Никто не мешает вам в винде использовать для шрифтов вместо имен PANOSE номера... И я уверяю Вас, это будет ещё сложноее чем разбираться с Иксовыми именами

>² Poor when compared with other platforms & windowing systems
For example?

ребятиши когда след. релиз иксов?и что в нём будет вкусного?

MAC, XP

> * Slow

Фиг его знает... И почему я не замечаю? Может, потому что ни Гномом, ни KDE не пользуюсь? Дык опять же, при чём тут X, ежли Гном тормозит?

> ² Too complex

Опять же -- с чем сравнивать? Может, Винда проще? Дык -- всяко проще, ибо задача отрисовки проще, чем задача отрисовки по запросам со всего мира...

> * No standard toolkit

О, блин! Ну, задолбали! Linux-way есть полное отсутствие стандартных тулкитов. Кому не нравится разнообразие -- юзайте Винду. Ей-богу, не сочтите за оскорбление -- тоже рабочая система. Но её путь -- все делают всё Микрософтовским способом. Впрочем, о чём это я -- есть Микрософт Цэ, а есть Борланд, а ещё есть VB -- и кажный же своих библиотек требует! Что, неужно никто не сталкивался?

> - Font specifications are unnecessarily complicated

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

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

С уважением -- Смоляное Чучелко

Мужик, конечно, бревно увидел. Только до него этого бревно видели уже толпы. И таких проектов было море. И будет еще столько же. Проблема в том, что иксы появились НА ПУСТОМ МЕСТЕ (реальных альтернатив не было) - и справились быстро стать стандартом (не только на программном - но и аппаратном уровне - а это не шуточки!). Чтобы протолкнуть даже ОЧЕНЬ удачное новое решение до уровня используемости, хотя бы сравнимого с исками,- нужна мощь какой-то ОЧЕНЬ большой компании (ну или всей open source community:). И даже такой мощи может не хватить (ну, я не говорю про МС). Поэтому мы можем радоваться, что не утихает творческая мысль энтузиастов - но к реальной жизни это все никакого отношения не имеет. Хотя, конечно, вся критика иксов со стороны этого господина - правильная и по делу. И, возможно, продвигаемая им архитектура, действительно даст ТАААКИЕ преимущества, что мы все просто закачаемся. Но, увы, это все совершенно не важно.

Да, кстати, очень хорошие слова автор пишет про интерфейсы на С++. Даже при всей его глубокой объектной ориентированности - у него хватило ума признать, что public API должен быть на С. Это камни, которые годами лежат в огородах QT/KDE и Mozilla - их туда даже кидать не надо.

А собственно говоря почему это public API должен быть на С, а не на С++?
Я могу утверждать что public API должен быть на CORBA :-))

Были уже такие, кто утверждали что публик апи должен быть на Корбе... Берлин зовётся. Вот только что-то я давно о нем не слыхивал

* Slow

>Фиг его знает... И почему я не замечаю? Может, потому что ни Гномом,
>ни KDE не пользуюсь? Дык опять же, при чём тут X, ежли Гном
>тормозит?


А то, что XWindow базируется на клиент серверной архитектуре и
,следовательно , требует для своей работы межпроцессной коммуникации
- Это ничего ? Это не замедление ?




> * No standard toolkit

>О, блин! Ну, задолбали! Linux-way есть полное отсутствие стандартных
>улкитов. Кому не нравится разнообразие -- юзайте Винду. Ей-богу, не
>сочтите за оскорбление -- тоже рабочая система. Но её путь -- все
>делают всё Микрософтовским способом. Впрочем, о чём это я -- есть
>Микрософт Цэ, а есть Борланд, а ещё есть VB -- и кажный же своих
>библиотек требует! Что, неужно никто не сталкивался?

Linux-way есть принцЫп "Кто в лес,кто по-дрова"
А Микрософт тем временем "слушает, да ест" :
Скоро будет .NET и от этого разнообразия можно будет избавиться.


Кстати, господа знатаки XWindows, скажите :
Действительно ли в XWindows нет контекста печати ?

Хорош ссориться, горячие финские парни...

Кому надо играть в игрушки и положить на сетевые возможности, будут использовать Y. А кому на игры положить, а надо заниматься серьезными вещами, продолжат использовать X. Linux/*NIX -- это свобода выбора, в отличие от.

А Хувиндоу систем будет?

> Кстати, господа знатаки XWindows, скажите :
> Действительно ли в XWindows нет контекста печати ?

есть print extension - если ты про это конечно

ммм.......согласен не всем нужны серверные фичи в X Window ....для домашних компов особенно. Пора уже разделить ее на две части. Жаль конешш что это долго развивается и когда появяться достойные релизы меня уже кто нить будет папашей называть ! :)

первоисточники

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

В данном случае http://www.opennet.ru/opennews/art.shtml?num=2920

Насколько я вижу, в последнее время на linux.org.ru появилось очень много "cut and paste" новостей с других русскоязычных ресурсов без указания первоисточника текста новости.

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

>Проблема в том, что иксы появились НА ПУСТОМ МЕСТЕ (реальных альтернатив не было) - и справились быстро стать стандартом

Не совсем так. Была NEWS, но Sun не захотела открыть исходники, а когда согласилась отдавать по стоимости копирования, было уже поздно. Да и стоимость копирования была оценена неадекватно -- $10000, кажется. У NEWS перед X были серъёзные преимущества, но не срослось.

AVB

Короче большинство постов здесь (и тот на который этот ответ) из-за того, что народ не читает "первоисточников", т.е. саму статью. Лично мое мнение эта работа - пример грамотного подхода и проетирования при решении поставленной задачи.

>Кстати, господа знатаки XWindows, скажите : >Действительно ли в XWindows нет контекста печати ?

Так где? В X или в Windows? Чайник.. блин!

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

Мне казалось, что NEWS - чуть по-позже. Хотя могу ошибаться...

Берлин, конечно, самый известный из альтернативных проектов. Ну, может, они чего-то добьются - в смысле реального использования. Но вряд-ли. В принципе, идея про public API на CORBA - хорошая. Только вот где бы взять свободную быструю реализацию CORBA с поддержкой тредов и пр. Остро нужен "Apache в мире CORBA":) Тогда, глядишь, станут делать API на CORBA. А до этого великого момента - будьте любезны делать их на С.

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

Все данные - в PDF, который лежит на сайте.

И не скомпиляется.
Автор так и пишет "я знаю, что оно не собирается... сейчас я занят, работать над этим начну в начале ноября"

То, что лежит у него на сайте - это так, даже не альфа...

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

Хотя... возможно что он поступит в аспирантуру и...

> Мне казалось, что NEWS - чуть по-позже. Хотя могу ошибаться...

Я тоже могу ошибаться ;) Но, насколько я читал, Х10 и NEWS появились примерно одновременно. Х11 -- позже. Х11 стал стандартом и Sun всё пыталась то реализовать X11 поверх NEWS, то наоборот. Ничего хорошего из этого не вышло.

Кстати, название автор выбрал неудачное.

2anonymous (*) (2003-10-01 08:07:31.738475):

>А Микрософт тем временем "слушает, да ест" :
>Скоро будет .NET и от этого разнообразия можно будет избавиться.

"Ох уж эти сказки, ох уж эти сказочники !" :)) Сколько уже .NET там стукнуло с тех пор как его выпустили на вольные хлеба ? А воз до сих пор и ныне там, даже стандартизация через ANSI не помогла и похоже тенденция плевания на .NET продолжает оставаться, а вот J2EE, в некоторой степени благодаря linux'у, продолжает дальше набирать обороты. Если бы Microsoft действительно заботилась о безопасности собственных систем, а не только о том как бы опять наебать юзеров на энное количество вечнозелёных, то может быть и начали создавать системы под .NET.

Так что пусть 'Микрософт тем временем "слушает, да ест"', а мы посмотрим как у них дела с лонгхорном пойдут и пока будем продолжать зарабатывать на производстве Java софта на линуксе :)

www.directfb.org

про клиент-серверную архитектуру

2 anonymous (*) (01.10.2003 8:07:31):

> А то, что XWindow базируется на клиент серверной архитектуре и,

Это хорошо. Система, не обладающая этим свойством, идет лесом.

> следовательно , требует для своей работы межпроцессной коммуникации - Это ничего ? Это не замедление ?

1) Блин, уважаемые любители GDI и осей от M$, когда таки вы узнаете, зачем нужен в вашей любимой ОСи csrss.exe и поймете, что все win32 API базируется на клиент-серверной архитектуре?!

2) По такой логике системные вызовы -- suxx, ибо требуют переключения контекста, а самая правильная ОС -- m$ DO$ :)

DirectFB suxx!

2 adarovsky:

> With the default build of the DirectFB library, only one DirectFB application may be running. However you have the option to use the multi-application core of DirectFB which allows for multiple DirectFB applications to run at the same time. Please note that this is still considered experimental. You have been warned!

( http://www.directfb.org/download/DirectFB/README )

Но это только цветочки!

> DirectFB applications communicate through a layer we called Fusion. This layer was previously implemented completely in user space using semaphores and message queues. But since 0.9.15 the Fusion Kernel Device is required which implements critical parts of fusion

Только window manager'-а в ядре и не хватало! В морг!

> Да, кстати, очень хорошие слова автор пишет про интерфейсы на С++. Даже при всей его глубокой объектной ориентированности - у него хватило ума признать, что public API должен быть на С. Это камни, которые годами лежат в огородах QT/KDE и Mozilla - их туда даже кидать не надо.

Ну, если он хочет, чтобы Y стал популярным за счет того, что его API можно было использовать из других языков программирования, то у него просто не было другого выхода. Авторы же QT/KDE/Mozilla не ставили перед собой такой цели. При этом их разработки не стали от этого менее популярными, правда, ведь?

Они стали менее популярными. Как минимум - на одного меня:). Каждый раз, когда я думаю - а не портировать ли gswitchit на KDE и самому туда перелезть, одна (не единственная) из причин, почему я этого НЕ делаю - С++. Готов спорить, что я не одинок. Хотя и оценивать статистический эффект нелюбви к С++ не стану:)

Просто моя мысль в том, что API на C++ реально будет использоваться из только С++ (разумеется, никто не отрицает возможности нахождения безумцев, создающих bindings к скриптовым языкам из С++ - но таких, обычно, мало). А API на C имеет ГОРАЗДО большие шансы быть использованным из других языков. Исторически. По причинам, очень верно указанным автором обсуждаемого проекта.

Есть один интересный проект: http://www.fresco.org/. Использует omniORB. Но почему-то этот проект всё время находится в полумёртвом состоянии :-(

>Просто моя мысль в том, что API на C++ реально будет использоваться
>из только С++ (разумеется, никто не отрицает возможности нахождения
>безумцев, создающих bindings к скриптовым языкам из С++ - но таких,
>обычно, мало).

Может быть немного оффтопик, но ИМХО API на C имеет смысл только в достаточно низкоуровневых вещах. IBM и Microsoft были первопроходимцами в плане реализации высокоуровневых объектных интерфейсов (SOM, COM, DCOM). Команда GNOME урок уже усвоила. CORBA и COM/DCOM рулят адназначна.

Заметьте, однако, что все эти архитектуры (*ОМ) можно использовать из голого С. И С++-обвязки делаются НАД С-шным API. Хотя, разумеется, программить COM на С - праздник достаточно печальный (пробовал немного). И в этом отношении мне тоже нравится подход GNOME (впрочем, как и подход windows.h) - ОО подход, выраженный на С. Да, это ОО не так органично, как в С++ - но public API на С++ создают больше проблем, чем решают.

И все эти *OM здОрово влияют на производительность - не всегда это можно себе позволить. Короче, мой идеал в этом вопросе: где можно - применяем *OM (с базовым API, выраженном в С!), в остальных случаях - просто public API на С. И да сгинут public API системного уровня, выраженные на С++/Pascal/ADA/.... Кто против?:) (Я знаю, ANDI будет против:) Кстати, я слышал, что в BeOS тоже системный API был на плюсах. Это правда? Да, и меня немало удивляет Apple с любовью к Objective C - впрочем, этого языка я не знаю, может, он не так испортил идеи С, как С++... И еще интересный вопрос - system API на Java - как думаете, братие, имеет смысл такое явление?

Да, шансов у С в этом отношении больше. Мысль о том, что API на C++ реально будет использоваться из только С++ программ совершенно справедлива. Точно так же, как и мысль, что, API на С _на_практике_ будет использоваться из только С программ. Доказательство - Гном. Почти все гном-приложения на голом С. Стоит овчинка выделки? Да, теоретически, мы можем использовать и Perl, и Python, и С++. Но на практике, где они, эти приложения, ради которых планировалась и разрабатывалась архитектура Гнома?

Вот и получается, что шансов у С больше. Но они так и остаются невостребованными (читай, ненужными).

>И С++-обвязки делаются НАД С-шным API.

Без проблем. Но как по мне, так уж лучше делать на голом C, чем линковать программу с "еще одной обвязкой". А ведь и не всегда они доступны, обвязки, к конкретной версии исходной библиотеки. А в 2 раза большее число используемых библиотек - означает в 2 раза большее число возможных багов. И, надежность страдает в первую очередь.

>Да, это ОО не так органично, как в С++ - но public API на С++ создают больше проблем, чем решают.

Не понятно. Каких проблем должно быть больше у программиста, разрабатывающего конечное приложение с помощью Qt, а не Gtk? При условии, что он знает С++ ;)

>И все эти *OM здОрово влияют на производительность - не всегда это можно себе позволить.

Я рискну предположить мысль, что все эти *OM (хорошее название :)) появились в результате желаний делать весь API на С. Потому как C++ программисту для работы с объектами достаточно базовых средств языка.

>И да сгинут public API системного уровня, выраженные на С++/Pascal/ADA/.... Кто против?:) (Я знаю, ANDI будет против:)

Qt - это системный уровень? Нет. Вот использование С для создания ядра/драйверов/системных программ я приветствую. Хотя очень интересна реализация на C++ ядра в BeOS. Поэтому все-таки я против :)

>Кстати, я слышал, что в BeOS тоже системный API был на плюсах. Это правда?

Да, правда. И очень здорово был реализован (вспомните размер системы).

>Да, и меня немало удивляет Apple с любовью к Objective C - впрочем, этого языка я не знаю, может, он не так испортил идеи С, как С++...

У него очень специфический синтаксис. Я не смог им проникнуться.

>И еще интересный вопрос - system API на Java - как думаете, братие, имеет смысл такое явление?

JVM? Причем аппаратный. Куда уж системнее.

Если ручками полапать его, кой-чего закоментировать, h-ник дописать, то собирается :)

Очень понравилось -Werr.

А так конечно, оно пока ничего особенного не представляет. Автору бы найти народа, что б драйверов понаписали, тем разных, обёртку для Xовых прог, что бы под его сервером работали. Тогда мот и пойдёт проект в массы.

Warlock

Я не С-программер,... поэтому шутки объяснять три раза 8)

1) Что есть -Werr? (-Werror - это ключ gcc, это я знаю)
2) Что у него за странные Makefile генерятся? 
 gcc -DHAVE_CONFIG_H -I. -I. -I. -I/usr/include/freetype2 -I.. -I.. -I/usr/include/freetype2 
меня несколько удивляют.

До кучи - редефайн MIN/MAX тривиален, даже я смог его найти и поправить...
Вызов fontDestroy в Y/widgets/console.c в consoleCreate() я тоже убрал - он там лишний, ИМХО. Вообще непонятно,
как он туда попал - учитывая, что создается font только при consolePaint()...

Не хватает Y/screen/simplerenderer.h - не понял, что он ожидает там увидеть... Сделал пустым.

Теперь обламывается на 
sdl.c: In function `sdlGetRenderer':
sdl.c:279: warning: implicit declaration of function `simplerendererGetRenderer'
sdl.c:279: warning: implicit declaration of function `simplerendererCreate'
sdl.c:279: warning: return makes pointer from integer without a cast

Я удивляюсь - где он там нашел integer? 
simplerendererGetRenderer возвращает struct Renderer *....