LINUX.ORG.RU

Игры перехватывают <Alt+Tab>


0

0

Наверное не я один имею такую проблему. Игры в полноэкранном режиме перехватывают сочетание Alt+Tab и их невозможно свернуть. Приходится извращаться и запускать их в отдельном терминале. Можно ли где-нибудь прописать, чтобы Xorg не позволял приложениям перехватывать Alt+Tab, чтобы этот сигнал доходил до оконного менеджера? Ведь он же не позволяет приложениям обрабатывать Alt+Ctrl+Backspace. Проблема то давняя...

Debian Lenny, KDE3.5, Fluxbox.

Спасибо за любую информацию.

>Игры

Даже пасьянс?

Зависит от игры. Вообще это обычно связано с банальным захватом устройств ввода для комфортной работы, в некоторых ситуациях может сгодиться etswitch

Gary ★★★★★ ()

>Alt+Tab
Бохтымой вы до сих пор не избавились от виндовых привычек? Переназачьте наконец смену окон на что нибудь более юзабельное. ММ keys например.

darkshvein ☆☆ ()

Я обычно по ssh захожу и убиваю прогу, но если можно послать сигнал иксам или вм'у (неразбираюсь точно), то наверно можно и свернуть ее, lirc опять же прикрутить по событию кнопки на системнике.

anonymous ()

> Можно ли где-нибудь прописать, чтобы Xorg не позволял приложениям перехватывать Alt+Tab, чтобы этот сигнал доходил до оконного менеджера? Ведь он же не позволяет приложениям обрабатывать Alt+Ctrl+Backspace.

man XGrabKeyboard

man XGrabKey

«Alt+Ctrl+Backspace», а точнее — «XK_Terminate_Server», — вообще не клиентский кейкод и дальше х-сервера он не уходит. а понятие оконного менеджера для х-сервера примерно такое: кто первый встал, того и тапки. некоторые приложения и тулкиты (особенно гтк, да) используют полный перехват клавиатуры для реализации контекстного меню, так что оконные менеджеры полный захват клавиатуры не делают, ради совместимоти (полный захват может сделать только одно приложение/подключенние, остальные посылаются кормить пингвинов). в результате в любой момент игрушка может перехватить клаву и сделать пользователю приятно (помню такое в ut).

arsi ★★★★★ ()
Ответ на: комментарий от arsi

Да, вместо Alt+Ctrl+Backspace можно использовать волшебную клавишу Alt+SysRq+k, работает всегда :3

Gary ★★★★★ ()
Ответ на: комментарий от Gary

> Alt+SysRq+k

> работает всегда :3

эпическое 4.2:

$ zgrep CONFIG_MAGIC_SYSRQ /proc/config.gz
CONFIG_MAGIC_SYSRQ=n

;)

arsi ★★★★★ ()

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

pevzi ★★★★★ ()
Ответ на: комментарий от arsi

>>CONFIG_MAGIC_SYSRQ=n

А стоит ли её отключать-то?

GotF ★★★★★ ()
Ответ на: комментарий от Gary

Ну. В том, что все полноэкранные приложения перехватывают все существующие хоткеи. Разве это нормально?

pevzi ★★★★★ ()
Ответ на: комментарий от pevzi

Точнее, выпиливают хоткеи, перехватывая полностью весь ввод с клавиатуры.

pevzi ★★★★★ ()
Ответ на: комментарий от pevzi

>>Точнее, выпиливают хоткеи, перехватывая полностью весь ввод с клавиатуры.

У меня переключение окон и десктопов на нумпаде - только dosbox его захватывает, остальные не трогают.

GotF ★★★★★ ()
Ответ на: комментарий от arsi

> кто первый встал, того и тапки

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

Получается, что это недоработка оконного менеджера, который так вот просто отпускает свои хоткеи? А Х-сервер вроде как всё правильно делает?

В результате Xorg показывает пальцем на KWin, мол это они виноваты, а KWin винит во всём Xorg. А баг остаётся, воз и ныне там.

Я может чего не понимаю, но мне кажется, что всем слоям Unix-сообщества уже давно понятно, что это баг. Или я не прав?

smirnovvdonsk ()
Ответ на: комментарий от smirnovvdonsk

> мне кажется, что всем слоям Unix-сообщества уже давно понятно, что это баг

А мне кажется, что мы тут вдвоем этот баг видим, а все остальные думают, что так и надо -_-

pevzi ★★★★★ ()
Ответ на: комментарий от pevzi

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

Это скорее проблема многих WM, даже не проблема а просто недоработка, например на fvwm не распространяется.

Lucky1 ★★★ ()
Ответ на: комментарий от smirnovvdonsk

> Вот именно в соответствии с этой логикой тапки должны принадлежать оконному менеджеру, но никак не игре, которая является его потомком.

должны, но только идеологически :) захватить клавиатуру может только одно единственное приложениеподключение к серверу (х-орг не поддерживает «невидимых» фильтров сообщений, хотя были попытки сделать соотв. расширение, хз чем всё закончилось). т.е. если это сделает квин, то уже ни одно гтк-приложение не сможет показать контекстную менюшку, убирающуюся по эск: контекстное меню не получает фокус ввода и, соответственно, может перехватить нажатие эск (или ↑↓↲, или буковок для быстрого доступа к пунктам типа «Exit») только полностью захватив клавиатуру. такие дела :)

arsi ★★★★★ ()
Ответ на: комментарий от pevzi

>То есть, иксы тут и правда не при чем?

Просто для иксов alt+tab не имеет значения, это не спец.последовательность. Тем более в разных WM сочетание клавиш может быть разным, не обязательно alt+tab.

Lucky1 ★★★ ()
Ответ на: комментарий от Lucky1

Да речь не только об альттаб. Съедаются все существующие хоткеи, кроме тех, что в запущенной игре.

pevzi ★★★★★ ()
Ответ на: комментарий от anonymous

>Я обычно по ssh захожу и убиваю прогу

Гы. Ректальная тонзиллэктомия? Вместо того, чтобы по-быстрому переключиться в IM и ответить на пришедшее сообщение и потом вернуться к игре, у нас требуется, или как во времена DOS выход из игры, или, вообще, заход с другой машины? :D

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

> заход с другой машины

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

То есть мы не можем решить проблему ДАЖЕ ЧЕРЕЗ ЗАДНИЦУ!!!

Позор, товарищи, позор. Это дискредитирует всю идеологию GNU-шного плюрализма.

smirnovvdonsk ()
Ответ на: комментарий от KRoN73

Кстати. Интересно, что игры, запускаемые под вайном, этим не страдают, а даже наоборот — переключение задач при запущенной игре происходит гораздо лучше, чем в венде — нет риска, что игра безвозвратно повиснет с черным экраном (:

pevzi ★★★★★ ()
Ответ на: комментарий от arsi

> только полностью захватив клавиатуру

Это что ж получается? Игра может перехватить даже Ctrl+Alt+F1?

smirnovvdonsk ()
Ответ на: комментарий от smirnovvdonsk

> Не с другой машины, а с другого терминала на той же машине

По ssh? ЧО?

pevzi ★★★★★ ()
Ответ на: комментарий от smirnovvdonsk

> Игра может перехватить даже Ctrl+Alt+F1?

Его, к счастью, не перехватывает. Потому что оно к иксам отношение имеет только косвенное.

pevzi ★★★★★ ()
Ответ на: комментарий от pevzi

> оно к иксам отношение имеет только косвенное

Дык, это значит, что не вся клавиатура доступна игрушке. И если мы отстояли одни хоткеи, значит можем завоевать и другие. Значит налицо баг.

smirnovvdonsk ()
Ответ на: комментарий от smirnovvdonsk

> не вся клавиатура доступна игрушке

Ну в данном случае потому что Ctrl+Alt+F1 не контролируется иксами. А проблема именно в иксах. А так да, самый что ни на есть конкретный баг.

pevzi ★★★★★ ()
Ответ на: комментарий от smirnovvdonsk

>> только полностью захватив клавиатуру

Это что ж получается? Игра может перехватить даже Ctrl+Alt+F1?


И не только игра. Нередко при глюках иксов Ctrl-Alt-Fn перестают работать :) Лечит только Alt-SysRq или ssh с другой машины.

KRoN73 ★★★★★ ()
Ответ на: комментарий от smirnovvdonsk

> Это что ж получается? Игра может перехватить даже Ctrl+Alt+F1?

у меня — да, у вас — нет) (у меня свои конфиги xkb, и XF86_Switch_VT_*/XF86XK_Switch_VT_* забиндены на другие сочитания.) игра, как и любое другое приложение, может перехватить только то, что х-сервер рассылает клиентам. а рассылает он это нечто только в том случае, если xkb это разрешил/запросил. в конфигах xkb можно задать примитивный скрипт на обработку некоторого символа. например (из дефолтного конфига):

interpret  XF86_Switch_VT_1 {
   action = SwitchScreen(Screen=1, !SameServer);
};
подобные interpret-ы обрабатываются ещё xkb, до передачи сообщения о нажатии самому х-серверу. т.е. xkb может передать х-серверу кейкод, а может и «переключись туда-то» или подобное или вместо кейкода, или вместе с кейкодом (опять же, зависит от скриптовконфигов xkb).

зы: любое приложение может загрузить собственный конфиг xkb-у, чем сделает пользователю очень приятно ;)

arsi ★★★★★ ()
Ответ на: комментарий от arsi

И это называется передовая ОС, готовая для десктопа… %)

Deleted ()
Ответ на: комментарий от Deleted

> И это называется передовая ОС, готовая для десктопа

Тихо, тихо. Это вы уже слишком раскритиковали. Перебор. У FreeUnix-ов слишком много преимуществ, чтобы так говорить. Полноэкранные игрушки здесь погоды не делают.

smirnovvdonsk ()
Ответ на: комментарий от smirnovvdonsk

#{здесь был текст про буфер обмена иксов} :}

Deleted ()
Ответ на: комментарий от Deleted

> И это называется передовая ОС, готовая для десктопа… %)

чорд, я даже хз что сказать %) сами по себе иксы, а точнее — их протокол — невероятная килерфича всех времен и народов, но они используются через такие восемь вложенных жоп, что чужой нервно курит всторонке. xkb — один из самых эпичных фэйлов, о (X)IM вообще можно петь душераздирающие баллады, а от glx у меня уже череп от перманентного фейспалма деформировался. а ведь это только вершина айсберга…

arsi ★★★★★ ()
Ответ на: комментарий от smirnovvdonsk

Под wine одна игра бывает виснет, мышь не двигается, Ctrl+Alt+F1 не работает, только magic sysrq или через lirc с пульта убивать приходится.

anonymous ()
Ответ на: комментарий от arsi

Интересно, можно там дело хотя бы частями решать или проще всё порушить и, мол, мы вместе мы новый дом построим?

Deleted ()
Ответ на: комментарий от Deleted

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

arsi ★★★★★ ()
Ответ на: комментарий от Deleted

> здесь был текст про буфер обмена иксов

Ээээ, а что с ним не так? Два буфера — один на Ctrl+C, другой на колесо мыши. Колесом копируется выделенный текст из открытого окна. Все работает, нареканий нет. ЧЯДНТ?

pevzi ★★★★★ ()
Ответ на: комментарий от arsi

> но если решать частями, то эти части будут достаточно большими и изменения повлекут за собой обязательное переписывание всего софта, напрямую использующего апи икслиб

Да не, если частями, то как раз таки будут шансы оставить совместимость, имхо. А вот все рушить и строить заново — не лучший вариант.

pevzi ★★★★★ ()
Ответ на: комментарий от arsi

> сами по себе иксы, а точнее — их протокол — невероятная килерфича всех времен и народов

А кто-то говорит, что использование графики через клиент-сервер — жуткое извращение, и влечет за собой более тормозной отклик и прорисовку :3 кстати, объясни, почему перечисленные тобой технологии вызывают фейспалм. Я просто интересуюсь, я не бумбум в этом, если честно.

pevzi ★★★★★ ()
Ответ на: комментарий от pevzi

Ууу… я их в последнее время часто вспоминаю, и куча народу говорит, что всё хорошо, так и надо, а на юзабилити положить, мол :) Про очищения буфера при выходе из приложения.

Deleted ()
Ответ на: комментарий от Deleted

> Про очищения буфера при выходе из приложения

Очищается только тот, что на колесо. Основной остается, только что проверил.
Ненуачо, лично мне это как-то не мешает. Но почему бы не написать багрепорт, ыаа?

pevzi ★★★★★ ()
Ответ на: комментарий от pevzi

> А кто-то говорит, что использование графики через клиент-сервер — жуткое извращение, и влечет за собой более тормозной отклик и прорисовку :3

за всё приходится платить ;)

> кстати, объясни, почему перечисленные тобой технологии вызывают фейспалм.

xkb поддерживает максимум 4 раскладки (640к хватит всем!). xkb абсолютно никак не связан с xim, в результате чего переключение раскладки не связано с переключением метода ввода. сам xim настолько ущербен, что тулкитам вроде qt/gtk приходится использовать собственные костыли (inputcontextplugin/immodule соотв.), что множит на ноль клиент-серверную архитектуру иксов: при запуске приложения через х-форвардинг плагин подключается к «родному» сокету uim/scim/*im и использует его. в результате нужно запускать ещё одну панель для мониторинга состояния метода ввода на удалённой машине. а если ещё один клиент подключится и начнут выкручивать руки этому *im-у? да он, наверное, вообще офигеет от того, что в системе одновременно 2+ окна с активным фокусом вводом). с xim таких проблем нет, все приложения используют *im через иксовый сокет, а не через сторонние, но вот архитектура xim — это нечто.

в оффтопике, кстати, это намного ровнее реализовано…

arsi ★★★★★ ()
Ответ на: комментарий от arsi

> за всё приходится платить
В том и соль, что клиент-серверный принцип добавляет офигенные фичи, а те сферические лаги не настолько уж и ощутимы.

xkb поддерживает максимум 4 раскладки

Ох, вспомнил одну вещь, да. Раскладка для всех окон задается глобально, нельзя задать отдельную раскладку для каждого окна стандартными средствами — нужно обязательно юзать костыли -_-

xkb абсолютно никак не связан с xim

Да, фейспалм, хотя для нас и не так актуально.

архитектура xim — это нечто

Дык это. Может как-то сообщить разрабам об этом всем?

pevzi ★★★★★ ()
Ответ на: комментарий от pevzi

Не остаётся :) Это просто у тебя костыль k/glipper или им подобный запущен (: А багрепорт куда тут писать, все в курсе давно.

Deleted ()
Ответ на: комментарий от Deleted

> Это просто у тебя костыль k/glipper или им подобный запущен
Вот тут уж не знаю. Дефолтная убунта, может они изкоробки чо и понапихали.

А багрепорт куда тут писать, все в курсе давно

А фигли тогда? -_-

pevzi ★★★★★ ()
Ответ на: комментарий от pevzi

В дефолтной убунте наверняка есть. Да они сейчас в KDE/Gnome вроде по дефолту грузятся. Причём KDE'шная иногда таки фейлит. Без понятия кто виноват, то ли klipper, то ли сами иксы. Как обновлюсь до 4.4, пожалуй, придётся багрепорт строчить на klipper… Если там это не пофиксено.

Deleted ()
Ответ на: комментарий от Deleted

> придётся багрепорт строчить на klipper

Да пофиг на костыли, почему в иксах это до сих пор не исправили?

pevzi ★★★★★ ()
Ответ на: комментарий от pevzi

> Дык это. Может как-то сообщить разрабам об этом всем?

они всё прекрасно знают :) даже пилят потихоньку. в qt4.4 (или 4.5, точно не помню) в модуле-обёртке для xim находил код попытки отослать глобальные координаты preedit-области и курсора для нормального позиционирования окна кандидатов. надо будет, кстати, попробовать, может оно уже даже работает и в gtk и поддерживается uim-ом (раньше при использовании xim окно вариантов всегда отображалось в фиксированном месте, слева внизу экрана, например).

arsi ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.