BDenis писал(а): ↑15.04.2009 07:57
Я конечно может чего не прокачал, но мне кажется диагноз не верен. Т.е. бага действительно связанна с wm_state, но то, как она связана для меня не очевидно.
В wait_for_withdrawn_state вся катавасия происходит при, не просто наличии wm_state, а когда и до тех пор пока оно равно WithdrawnState:
Код: Выделить всё
while (data->whole_window && ((data->wm_state == WithdrawnState) == !set)) // set =false в нашем случае
Т.е. проблема, вроде, не в отсутствии wm_state, а в том, что его никто не изменяет при закрытии (и не понятно кто ставит, если это не nx), а это бага уже другого порядка и пока никак не локализована, так что писать про нее бесполезно.
Разубедите? Может не догнал чего?
Противоречие в регистре символов: WM_STATE - свойство окна х-сервера, data->wm_state - член структуры х-клиента.
Можно сразу установить data->wm_state посредством вызова get_window_wm_state() (а оттуда XGetWindowProperty()). Этого при закрытии окна не делается, хотя по коду при отсутствии свойства, data->wm_state в Withdrawn и станет(нет, но можно исправить иначе).
Вместо этого в wait_for_withdrawn_state() (далее XCheckIfEvent) проверяется PropertyNotify. В строгом соответствии букве ICCCM проверяется факт изменения или удаления WM_STATE. Если свойства нет (как правильно замечено, его должен выставлять wm), а удалить отсутствующее нельзя, то и факта нет.
Все правильно, я же писал, что это и есть нюанс, а не бага. Чтобы от него избавиться, надо перед упомянутым циклом установить data->wm_state с помощью get_window_wm_state() и еще проверить data->wm_state на -1, тогда цикл не выполнится ни разу, и задержки не будет.
P.S. Много раз исправлял, но что-то голова плохо соображает после ночи длиною в час. Простите.