3
В чем разница между _NET_ACTIVE_WINDOW и XGetInputFocus()? Всегда ли они указывают на одно окно? Когда вы используете один над другим?Разница Xlib между _NET_ACTIVE_WINDOW и XGetInputFocus
Спасибо.
A
ответ
2
Нет, они не всегда указывают на одно и то же.
_NET_ACTIVE_WINDOW - вещь WM. Он не будет указывать на окно, не управляемое WM.
Фокус ввода не знает или не заботится о WM (кроме того, что он установлен в основном от WM). Он может быть установлен любой программой в любое время в любое окно: внутреннее, переопределенное-перенаправление или даже несвязанное управляемое окно (хотя это мало программ).
То, что вы хотите использовать очень сильно, зависит от ваших конкретных потребностей. Обычные приложения тоже вряд ли будут использовать. Если вы хотите отправлять события клавиатуры, используйте XGetInputFocus. В большинстве других случаев вы, вероятно, хотите _NET_ACTIVE_WINDOW.
2
Главное отличие в настройке больше, чем при получении. При настройке фокуса (активации окон) вы предпочитаете атом над функцией xlib, потому что тогда диспетчер окон может обрабатывать ваш запрос по-другому - например, если вы хотите активировать окно с модальным диалогом вверх в то время, WM может сфокусируйте это диалоговое окно вместо самого окна, или если пользователь отключил фокус-кражу, WM может просто выделить окно, а не фокусировать его.
Есть несколько небольших различий в получении слишком, основываясь на одной и той же идее, хотя я не уверен, в чем все различия, я думаю, что это может быть специфическое приложение. С программами, которые я написал, получение свойства и фокус возвращают одно и то же окно. Однако с Firefox он возвращает два разных окна - активным является окно, которое мы ожидаем, но основное внимание уделяется скрытому окну. Я не знаю, почему это так, но это так.
_NET_ACTIVE_WINDOW изолирует вас от данных вида реализации приложения лучше, чем XGetInputFocus. Что-то вроде диспетчера окон или клавиатурного граббера может интересоваться конкретными деталями, но приложение, спрашивающее, активно ли оно (или просит активировать), должно использовать атом.
Читать немного больше здесь тоже кстати: http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472702304
+1
IOW разница неясна и произвольна. Альтернативным ответом будет: _NET_ACTIVE_WINDOW, чтобы исправить тот факт, что приложение никогда не должно разговаривать с API-интерфейсом механизма, но только с API-интерфейсом политики, но поскольку X предоставляет как для пользователя в том же API теперь у нас есть этот беспорядок. – cap
+0
Да, это мое чувство. Я действительно удивлен, что в моих тестах меню диспетчера окон ничего не изменило. Он просто отфильтровывал события вне очереди, фактически не фокусируя их. Но Firefox один странный - это не WM, который делает это ... но я подозреваю, что модальный диалог тоже может это сделать, у меня просто нет программ, которые на самом деле их используют. (Я МОЖЕТ использовать модальные диалоги в качестве пользователя.) –
Я хочу знать, активное окно по двум причинам: 1) знать, если мое приложение является активным и 2), чтобы получить активный дисплей, т.е. дисплей, который в настоящее время имеет фокус клавиатуры. – cap
Я не уверен, как этот ответ может помочь мне решить, какой метод использовать. Похоже, что XGetInputFocus() является более безопасным вариантом, учитывая, насколько плохие WM вообще. Мне непонятно, когда _not_ использовать его или почему _NET_ACTIVE_WINDOW было добавлено в первую очередь. – cap
«Я хочу знать» не является достаточной причиной. Почему вы хотите это знать? Как именно эта информация влияет на поведение вашего приложения? –