Разница xlib и xcb

xcb это тонкие обёртки над отправкой/приёмом из x11-сокета. Скорее всего никакой пользы ты от них не получишь.

Позиционирование как «более современного» ложное, это просто чуть более низкоуровневый и заметно менее удобный в большинстве случаев вариант. Ну и документации к данной библиотеке ты почти не найдёшь, придётся смотреть описание протокола и угадывать как оно ложится на её функции.

ICCCM тут не особо при чём. Это само по себе надстройка над базовым функционалом xlib (и кстати необязательная к поддержке софтом), это не часть собственно протокола, а рекомендации по его применению. Сравнение xlib vs xcb на неё не особо влияет.

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

Если проводить очень грубую аналогию, то разница как между OpenGL и Vulkan. Первый имеет ниже порог входа, но плохо дружит с многопоточностью и микрооптимизациями (из-за того что абстракция достаточно толстая, проблематично контролировать что там под капотом происходит), второй требует около тысячи строк на Hello World с треугольником (для сравнения OpenGL даже с шейдерами укладывается в <300), зато можно выжать максимум из железа.

Короче, если пишешь свой GUI фреймворк или оконный менеджер, то XCB must have. Если тебе нужно просто пару кнопок показать, то Xlib скорее всего предпочтительнее. Впрочем, для пары кнопок обычно удобнее использовать Qt/GTK или на худой конец SDL.

XCB «современнее», потому что по факту сейчас уже никто не пишет прикладной софт на голом API X11, а пользуются фреймворками и прослойками. А уже они, в свою очередь, используют XCB под капотом (потому что он реально лучше для фреймворков за счёт большего контроля). В итоге получается, что новая кодовая база поголовно использует XCB, а на Xlib сидит старый софт написанный без фреймворков.

Xlib тоже не так что бы прямо синхронный. Просто там асинхронность немного спрятана.

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

сейчас уже никто не пишет прикладной софт на голом API X11, а пользуются фреймворками и прослойками.

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

XLib не нужна вообще, если не занимаешься retro-кодингом

это уже манипулятивное заявление, не надо.

Назови прикладные программы, у которых первый релиз вышел в последние 5 лет, они не являются нишевым оконным менеджером (для которых на самом деле XCB предпочтительнее, но у авторов была цель выкатить MVP минимальными усилиями) и они используют Xlib.

Да я как-то не слежу за первыми релизами новых программ. Не думаю что их, если исключить игры для оффтопа, исключить не-гуи, исключить нейрослоп и ограничиться С/С++, вообще большое количество.

Но дело не в этом. По статистике, наверно, и правда фреймворками пользуются чаще, но для категоричного заявления «никто не пишет» этого явно недостаточно. Кроме того, у этого заявления, ввиду его (ложной) категоричности, получается эмоциональный подтекст вида «не трогай это старьё», тоже обманывающий, почему я и сказал что заявление манипулятивное.

За себя могу сказать, что хоть я за последние 5 лет и не начинал новых гуи-прог (пользуюсь теми, что начал делать раньше), но если сейчас потребуется - я скорее всего всё так же буду использовать xlib. Прослойки - могут быть, но не в виде огромных фреймворков а в виде своего же небольшого кода (у меня есть такая, кстати начатая ещё в оффтопе а потом я туда поддержку иксов добавил, но она не везде полезна).

Насколько сильно у них отличается API?

все намного проще - xcb он сгенерированный, поэтому документации нет, API практически не отличается (если писал на XLib и у тебя работает мозг), все те же самые функции, когда это понимаешь достаточно доки https://xcb.freedesktop.org/manual/modules.html

асинхронщина там по одному сценарию различие в обработке ошибки (XLib возвращает сразу) - xcb основной API с суффиксом xcb_xxx_checked возвращает cookie, статус выполнения которого (и ошибку) можно проверить позже через xcb_request_check, и есть запросы которые должны вернуть результат это с суффиксом xcb_xxx_reply, и есть методы без таких проверок xcb_xxx - где если будет ошибка, то она вывалится в event цикл.

команда xcb заявляет что это быстрее xlib, и уже с этим никто не спорит. Thread safe. Но если делать по варианту _checked получаешь как Xlib

проблема с xcb - если пишешь все вручную cheched/unchecked/reply это также много ненужного повторяющегося кода, потом ты начинаешь подтягивать template/define и получается более менее.

XLib возвращает сразу

В большинстве случаев - нет. Сразу возвращает только XSync и ещё несколько синхронных функций, всё остальное асинхронное.

команда xcb заявляет что это быстрее xlib, и уже с этим никто не спорит

Нет никакой «команды xcb». Насчёт «быстрее» - сомнительно.