Событие не получено, когда клиент X11 устанавливает _NET_WM_STATE_DEMANDS_ATTENTION - PullRequest
1 голос
/ 13 мая 2019

Я создаю панель задач для рабочего стола X11, и до сих пор мне удавалось обнаруживать новые и удаленные окна и изменения заголовков и значков окон.

Однако, несмотря на настройку каждой маски событий, которую я могу придумать в клиентских окнах, я не смог получить никаких событий, когда тестовое приложение добавляет атом _NET_WM_STATE_DEMANDS_ATTENTION к свойству _NET_WM_STATE.

Я использую Qt5 и записываю входящие события X11, используя installNativeEventFilter. Однако я также попытался использовать xprop -spy и вижу там ту же проблему: даже при опросе свойства _NET_WM_STATE показано добавление и удаление атома, событие изменения свойства никогда не принимается. Похоже, что Fluxbox не подхватывает его, пока что-то еще не заставит его повторно запросить окно.

Мой код фильтра событий похож на этот:

xcb_generic_event_t* ev = static_cast<xcb_generic_event_t*>(message);
uint32_t type = ev->response_type;
switch (type) {
case XCB_PROPERTY_NOTIFY: {
  xcb_property_notify_event_t* pev =
      reinterpret_cast<xcb_property_notify_event_t*>(ev);
  qDebug() << "property" << pev->window << pev->atom << (int)pev->state;
  break;
/* snip */
default:
  qDebug() << "unrecognized event" << type;
};

Мое тестовое приложение использует QApplication::alert() по таймеру для установки флага внимания.

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

1 Ответ

0 голосов
/ 17 мая 2019

Оказывается, что собственный фильтр событий Qt5 на X11 не проходит все последовательно. Я еще не выделил эту ошибку , но я написал свой собственный минималистический цикл событий xcb на отдельном соединении для обработки действий по управлению окнами, и он прекрасно работает.

...