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

>Игры

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

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

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

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

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

man XGrabKeyboard

man XGrabKey

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

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

> Alt+SysRq+k

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

эпическое 4.2:

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

;)

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

В чём ошибка?

>>CONFIG_MAGIC_SYSRQ=n

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

По ssh? ЧО?

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

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

Тоже этот баг достает. :(

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

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

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

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

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

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

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

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

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

interpret  XF86_Switch_VT_1 {
   action = SwitchScreen(Screen=1, !SameServer);
};

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

svu что-то говорил, но я не помню :)

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

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