Документация по X (посоветуйте)

айда на tronche.com. ну и маны, сырцы... ни одной книги не видел, самому интересно.

а тебе зачем?

http://del.icio.us/v04bvs/x11 90% инфы там брал, когда надо было. Ещё Qt читал иногда, хорошо читается.

Как то видел книгу по иксам, хорошая книга, основательная, но ссылки не осталось.

> а тебе зачем?

Для общего развития. :)

> http://del.icio.us/v04bvs/x11 90% инфы там брал, когда надо было. Ещё Qt читал иногда, хорошо читается.

> Как то видел книгу по иксам, хорошая книга, основательная, но ссылки не осталось.

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

У меня основные проблемы были с интернационализацией, всякими японскими вводами и шрифтами (через freetype чтобы рисовать). А сам windowing достаточно простой, особых затруднений быть не должно.

http://www.rahul.net/kenton/index.shtml

Задавался этим же вопросом тут когда-то, бросили книжкой - В.Д. Валединский, А.А. Корнев, В.М. Староверов - "OS UNIX. Работа и программирование в XWindows". Вроде ничего так, хоть и базово. Могу прислать на мыло или по джабберу

может выложишь на быдлоифолдер хотя б какой-нибудь?

Буду весьма благодарен. Выложи куда-нибудь или на bohtvaroh [[[[ at }}}} gmail.com.

Спасибо!

http://station-mir.ginnungagap.in.ua/Programming-Guide-X-Window-System--rus.pdf

Connection refused. :(

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

большое спасибо!

а может кто-нибудь объяснить зачем нужна libxcb при живой xlib?

>а может кто-нибудь объяснить зачем нужна libxcb при живой xlib?

блин, ну а на офсайт зайти? http://xcb.freedesktop.org/Features/
жаль конечно, что в литературе xcb практически не упоминается

<Ъ>
Xlib has been the standard C binding for the X Window System protocol for many years now. It is an excellent piece of work, but there are applications for which it is not ideal, for example

    * Small platforms: Xlib is a large piece of code, and it is difficult to make it smaller.
    * Latency hiding: Xlib requests requiring a reply are effectively synchronous: they block until the reply appears, whether the result is needed immediately or not.
    * Direct access to the protocol: Xlib does quite a bit of caching, layering, and similar optimizations. While this is normally a feature, it makes it difficult to simply emit specified X protocol requests and process specific responses.
    * Threaded applications: While Xlib does attempt to support multithreading, the API makes this difficult and error-prone.
    * New extensions: The Xlib infrastructure provides limited support for the creation of X extension client side code.

For these reasons, among others, we are working on XCB, an X protocol C Binding which is designed to solve the above problems and thus provide a base for

    * Toolkit implementation.
    * Direct protocol-level programming.
    * Lightweight emulation of commonly used portions of the Xlib API (see the XCB "utils" library for a start on this).
</Ъ>

OT. стоит дать ссылку на свой сервер на ЛОРе, и через полчаса появляются запросы вида

81.206.82.96 - - [04/Jun/2008:09:08:51 -0400] GET /stats/awstats.pl HTTP/1.1 "404" 203 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)" "-"
                                                                                                                               ^^^^^^^^^^
Одно слово - Нидерланды.

>а может кто-нибудь объяснить зачем нужна libxcb при живой xlib?

http://www.linuxshowcase.org/2001/full_papers/massey/massey.pdf

Есть предположение, что это стёб. :D

В начале пути к цели, энергия идущего достаточна, чтобы легко щёлкать недостатки xlib, не интересуясь xcb, поэтому все начинают с xlib и часто на нём и останавливаются. И только на следующей итерации разработки, когда наступает пора рефакторинга, xlib аккуратно заменяется на xcb, и то не всегда. (Зачем, если недостатки xlib отважно побороты через изобретение необходимых велосипедов на энтузиазме. Часто велосипеды проще знакомства с xcb.)

Реально, человеку с горящими глазами, недостатки xlib не кажутся существенными. Так было со мной (-;

irc_007_1

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

irc_007_1

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

> Реальна ли какая-та альтернатива с более совершенной архитектурой?

Рисовать на локальном фрейм-буфере и гонять до клиента содержимое, на лету аппаратно пожатое в мпег. В принципе униховые терминалы уже к этому начинают стремиться, поскольку работать удалённо по Х-протоколу выходит медленно. А вот была бы нативная реализация под фрейм-буфер, то плюс к тому можно было бы пописывать разные реализации этого буфера с выводом в сеть, на произвольные совокупности мониторов, на нестандартные устройства вывода типа всяких ТВ-выходов.