Очень странный баг

А если двигать этот диалог, остается просвет?

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

Стираются, когда приложение перерисовывает диалог.

Можно посмотреть во встроенном GTK3+-отладчике: CTRL+SHIFT+I –> Visual –> Show Graphic Updates.

Получается что? Получается, gtk3 берёт хэндл top-level окна (не клиентского, а именно openbox-ового окна) и зачем-то в него рисует.

То есть ты считаешь, что top-level окно находится поверх всех остальных окон? Как ты тогда видишь другие окна?

То есть ты считаешь, что top-level окно находится поверх всех остальных окон?

Ничего не понял. Что я считаю?

top-level окно, о котором ты говоришь. Оно позади всех остальных окон? Или все остальные окна позади него? Или, может, оно где-то посередине?

Можно посмотреть во встроенном GTK3+-отладчике: CTRL+SHIFT+I –> Visual –> Show Graphic Updates.

Посмотрел.

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

Так вот, эта полоса не отсвечивает красным при наведении мыши, хотя должна перерисовываться. Вместо этого появляется полоса через другое окно.

Похоже, что приложение пытается её перерисовать, взяв неверный хэндл окна.

У poedit, кажется, еще wxWidgets под капотом, так что разобраться будет сложно.

Если это косяк не приложения, а библиотеки, надо бы накидать на чистом gtk3 минимальный пример, воспроизводящий баг. Но мне сейчас некогда.

top-level окно, о котором ты говоришь. Оно позади всех остальных окон? Или все остальные окна позади него? Или, может, оно где-то посередине?

Есть корневое окно иксов.

Есть WM.

Есть приложения.

WM мониторит, когда приложения создают свои окна.

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

Получается такая штука:

root
  WM-proxy1
    app1
  WM-proxy2
    app2
  etc...

Что, основы работы оконной системы в иксах тебе нужно объяснять? Вроде сам знаешь.

Вот каким образом и зачем приложение взяло хэндл окна WM-а и начало в него рисовать - вопрос…

А под Wayland’ом проблема присутствует?

Если это косяк не приложения, а библиотеки, надо бы накидать на чистом gtk3 минимальный пример, воспроизводящий баг. Но мне сейчас некогда.

Да, если накидаешь, я проверю на чистой Fedora 32 на X.Org и Wayland сеансах. И лучше, наверное, не на чистом GTK+3, а на wxWidgets, так как PoEdit вроде как использует его.

На стандартной Adwaita-теме тоже глитч имеется? Баг только в этом приложении или ещё где-то проявляется?

У окна, кстати, модальность выставлена, верно? Не забудь про это если будешь делать минимальный пример.

P.S. https://github.com/vslavik/poedit/blob/master/src/findframe.cpp

Если будешь делать минимальный пример с wxWidgets, стоит обратить внимание на эти флажки поискового окошка:

https://github.com/vslavik/poedit/blob/6bee06cfa8f083951eb813f66fe0628e8d354581/src/findframe.cpp#L68-L69

Спасибо за развёрнутый ответ. К сожалению, это ответ не на тот вопрос, что я задавал.

Top-level окно, о котором ты говорил в заглавном сообщении, где находится? Оно находится поверх всех остальных? Или оно позади всех остальных окон?

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

А это не баг композитинга? Проверь с отключенным компотом

openbox --replace