>>> Ну Вы же сами пишете, что свойства, которые важны _для_сервера_ это другое,
>> где? я такого не писал.
> В предыдущем ответе https://www.opennet.ru/openforum/vsluhforumID3/122311.html#286
> "сравнивать изначально сдизайненый для сетевой прозрачности протокол и прибитый гвоздями
> к локалхосту протокол".
> Исходно смысл несколько шире, вывод я сам сделал.смысл совсем другой: API, подразумевающий сетевую прозрачность, необходимо будет отличаться от API, который под сеть не заточен вообще.
впрочем, `SetWindowLong()` можно проэмулировать в xlib (если там ещё нет чего-то похожего, я как-то никогда даже не интересовался). ценность, однако, сомнительная — как раз потому, что обработка событий не колбэками сделана. поэтому пользователю xlib всё равно придётся хранить внутренние структуры для диспатчинга сообщений, а в них вполне натурально можно положить любые необходимые данные, без помощи xlib.
>> серверу вообще наплевать, какие свойства к окну
>> прикреплены.
> Серверу может и наплевать на всё, кроме XCB_CW_CURSOR, а той штуке, которая
> рисует заголовок окна интересны некоторые _MOTIF_WM_HINTS, или же _NET_WM_NAME.
и ещё куча других интересных. которые обрабатываются клиентским приложением на стороне клиента, а серверу по-прежнему наплевать. сервер дал API для того, чтобы прицепить к окну любую бирочку с данными, и больше его особо ничего не интересует.
> Так в SetWindowLongPtr как раз и отправляют указатель на ту структуру. При
> получении сообщения сообщения вытаскивают и далее по указателю с данными и
> работают.
всего лишь один из возможных путей, и далеко не самый лучший. потому что этих слотов там всего несколько штук, и новые никак удобно не создать. тем более именованые. да и система обработки событий в колбэках без нужды ограничивающая. например, реализация схемы sink/bubble в X11 выглядит вполне естественно, а в winapi это будет жуткий костыль.
>>> И вообще был удивлён ситуацией: интерфейс разработан давно, но документация в
>>> незавершённом состоянии.
>> потому что далеко не всем нравится программировать на уровне протокола иксов.
> По-моему, такие берут GTK, Qt и тому подобное (ой, про Electron забыл).
> Кто сунется ниже, тому уже все кошки чёрные.
нет. xlib вполне юзабельна. а вот прямая работа с протоколом иксов (чем, по сути, и является xcb) — много геморроя непонятно зачем.
> Так то xlib вроде как есть, но если приглядеться, то это немного
> не xlib:
это вполне оно. как я сказал, xcb — это библиотека для работы с протоколом иксов. практически uncooked. вполне естественно, что xlib спокойно реализуется поверх неё. но непонятно, зачем пытаться говорить с иксами напрямую лично: для этого должно быть *очень* веское обоснование. вместо которого обычно: «мне рабинович напел, что xlib медленная и неэффективная, а xcb модный, быстрый, и к нему прилагается бесплатный минет.»
