Board.KolibriOS.org

В ядро ревизии 92 добавлена поддержка горячих клавиш.
1. Пользователям.
Соответственно изменено приложение @panel. В частности, поток, отвечавший за постоянное сканирование клавиатуры, перестал расходовать зря процессорное время, после чего удалось его объединить с основным потоком. (Итого в системе стало на один поток меньше.) Новый код залит на svn, кроме того, бинарник временно (до очередного дистрибутива) можно скачать здесь:
http://diamondz.land.ru/@panel
http://diamondz.land.ru/kernel.mnt (бинарник ядра, как обычно).
Заодно переписал работу с файловой системой на 70-ю функцию.
Функция 18.12 в новом ядре просто возвращает 0. Можно рассматривать это как средство для обратной совместимости, можно считать зарезервированным на будущее. В результате старая @panel с новым ядром, равно как и новая @panel со старым ядром, работают, но не поддерживают горячих клавиш.
Панель реагирует на следующие комбинации: (я их не менял)
LShift+RShift - переключение то ли раскладки, то ли языка системы
Ctrl+Shift - наоборот (то ли языка, то ли раскладки, сейчас точно не помню)
Ctrl+Alt+F12 - для вызова приложения end
Alt+Win - для вызова menu
Alt+F4 - убивание активного окна; кстати, я разобрался, почему раньше это не срабатывало на некоторых приложениях - не срабатывало в точности на использовавших сканкоды - из-за того, что был неправильно указан сканкод клавиши F4 (ASCII-код был указан правильно, а это были две разные ветки кода - поэтому на части приложений работало, а на части нет)
Alt+Home/Alt+UpArrow - прокрутка панели вправо/влево. Эту комбинацию придумал не я, она существует начиная с Kolibri 0.5.3.0, но раньше она срабатывала только если приложение использует сканкоды (возьмите Kolibri 0.5.3.0. Запустите scancode. Понажимайте Alt+Home/Alt+Up, учитывая, что панелька ленивая и перерисовывается когда считает нужным. Закройте scancode (ещё раз убедившись, что Alt+F4 не работает). Откройте keyascii. Снова понажимайте. Теперь проделайте такие же операции с текущими ядром и панелью. Ну и как?)
Скорее всего, её создатель (видимо, Mario79, он добавил возможность прокрутки панели) имел в виду что-то другое, но что?
Кстати, по поводу Alt+стрелки. Когда-то давно это приводило к перемещению курсора мыши. Теперь код в keyboard.inc всё ещё есть, но почему-то не работает. Будем исправлять или просто забьём на эту возможность? А то Alt+стрелки могут применяться в разных программах. Скажем, в (Windows-) Far'е Alt+Home/End/LeftArrow/RightArrow служат для показа очень длинных имён файлов, и мне кажется разумным добавить их в kfar.
2. Программистам.
Горячие клавиши добавляются/удаляются подфункциями 3 и 4 функции 66. При нажатии зарегистрированной комбинации приложение получает событие 2 - такое же, как и при нажатии на обычную клавишу, я не стал плодить события... Прочитать такую комбинацию можно той же функцией 2, только в этом случае она возвращает al=2. Подробности можно прочитать в документации. По поводу обратной совместимости можно не волноваться - если программа не устанавливает горячих клавиш, то извещений о них она не получает.
Демонстрационный пример "подвешивает" на NumLock вызов calc.
http://diamondz.land.ru/@numcalc
http://diamondz.land.ru/@numcalc.asm
Желающие могут добавить его в autorun.dat, ресурсов он практически не кушает. (Памяти - одна страничка (меньше нельзя), процессорное время - только при инициализации и при нажатии NumLock). Пожалуй, это самая маленькая программа, которая может использоваться в практических целях - 110 байт, на втором месте vrr_m - 150 байт.

В ядре предположительно есть баг с горячими клавишами. При нажатии горячей комбинации последний символ комбинации не возвращается текущему активному приложению. К примеру, если запустить SCANCODE и начать нажимать Ctrl+Shift хорошо видно как последний сканкод не возвращается. Из 4-х сканкодов возвращается только 3. Если нажимать и отпускать каждую клавишу отдельно, то возвращаются все сканкоды, т.е. последний сканкод съедает именно горячая комбинация. Раньше я списывал такое поведение на то что меняется фокус приложения. Но панель некоторое время назад была переписана и сама переключает раскладки клавиатуры, без вызова приложения SETUP.

UPD. Для трактористов:

Подфункция 4 - установить общесистемную "горячую клавишу".
О нажатии "горячей клавиши" извещаются только приложения, установившие её; активное приложение (к которому поступает весь нормальный ввод) таких клавиш не получает. Извещение заключается в посылке события с кодом 2. Прочитать "горячую клавишу" можно так же, как и обычную, - функцией 2.

Функция 2 - получить код нажатой клавиши.
....
если есть "горячая клавиша", то возвращается al=2, ah=сканкод нажатой клавиши (0 для управляющих клавиш), старшее слово регистра eax содержит состояние управляющих клавиш в момент нажатия горячей клавиши

Обычный же поток данных:

если буфер непуст, то возвращается al=0, ah=код нажатой клавиши, старшее слово регистра eax обнулено

Должен возвращаться всегда, если окно является активным.

SVN r. 2611 исправление для р.92 (вы видите правильный номер - иногда приходится выкапывать мамонта).

Я имею планы добавить клавишу Win как равнозначную по статусу клавишам: Ctrl, Shift, Alt. Соответсвенно будут скорректированы, с учетом обратной совместимости, функции: 66.3, 66.4, 66.5

Мои планы по предыдущему посту отменяются. Во-первых, я смог сделать реализацию обработки Win на уровне приложения @PANEL. Во-вторых, реализация в ядре (подобно существующим управляющим клавишам Shift, Ctrl, Alt) не позволяет отлавливать момент отжатия клавиши Win, если оформить обработку в самой системной функции. А без отлова отжатия Win (win key up) не получается реализовать комбинации Win+клавиша (для выполнения каких либо действий) и просто отжатие Win (win key up) для запуска меню.

А в чём именно проблема добавить отжатие, чем кнопка так уж отличается?
Ну да, можешь не объяснять в деталях, в код могу посмотреть, но тогда просьба потыкать носом в нужную функцию.

Там реализация для 66.3 ( [kb_state] ) хитрая - отлавливается в явном виде лишь сканкоды нажатия клавиш Shift, Ctrl, Alt. Для этих клавиш как ни странно этого достаточно, а вот для Win нужно отлавливать момент отжатия, чтобы разделить Win+клавиша и просто Win. Иначе тупо все время Win срабатывает.

Посмотреть можно в (root)/kernel/trunk/hid/keyboard.inc

З.Ы. Да и не нужно это - все нормально решается наличием простенького флага для Win в приложения. К примеру, я сделал так в панели задач - SVN r.2619

Возможно, это фича? Если приложение A зарегистировало Shift+Ctrl+Alt+F7 как горячую клавишу и при активном приложении B пользователь нажимает Shift+Ctrl+Alt+F7, вряд ли имеет смысл посылать её приложению B, которое может сильно удивиться.

Added: во всяком случае, такое поведение документировано:

sysfuncr.txt wrote: ----- Подфункция 4 - установить общесистемную "горячую клавишу". -----
О нажатии "горячей клавиши" извещаются только приложения,
установившие её; активное приложение (к которому поступает
весь нормальный ввод) таких клавиш не получает.

Mario wrote:SVN r. 2611 исправление для р.92 (вы видите правильный номер - иногда приходится выкапывать мамонта).

И вот, работаю я в текстовом редакторе, и жамкаю Альт-таб. В текст вставляется куча табов. Так и должно быть? Какие методы борьбы?

Приложение не отфильтровавшее ввод ненужных ему кодов ССЗБ и должно быть расстреляно на месте преступления поправлено зубилом и молотком.

UPD. В каком это текстовом редакторе происходит? Tinypad никаких лишних табов не добавляет. Если в портированном VIM, то тут уж я умываю руки. По крайней мере отсутствие глобальной проблемы (во всех приложениях) залипания Shift, Ctrl, Alt важнее проблем одного ленивого приложения.

В KFAR же. И в VIM. И во всех других программах, которые обрабатывают не скан-коды, а ASCII. (Хотя спрашивают, видимо, именно скан-коды). Так как в shell такого нет - делаем вывод, что Vim и KFAR используют неверную функцию shell.

На shell не нужно ориентироваться, тем более, что там:

Вскрытие показало, что пациент скончался от вскрытия KFAR и VIM (console.obj) используют сканкоды, а не ASCII. Выловлено выводом на доску отладки от кода ядра в keyboard.inc:

Spoiler:

Code: Select all

.found_free:
        mov     [edi], eax
        movzx   eax, ch
        cmp     bh, 1
        jnz     @f
        
        xor     eax, eax
@@:
        mov     [edi+4], ax
        mov     eax, [kb_state]
        mov     [edi+6], ax
; check for ASCII mode
	movzx	eax,byte [keyboard_mode]
        DEBUGF  1, "K : backg x %x\n",eax
        cmp     [keyboard_mode], 1 ; 0 = ASCII, 1 = scancode
        je      .nohotkey
        popad
        jmp     .exit.irq1
;--------------------------------------
.nohotkey:
        popad
        cmp     [keyboard_mode], 0; return from keymap
        jne     .scancode

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

SVN r. 2633 в редактор KFAR добавлена корректная обработка системных горячих комбинаций Alt+Tab и Shift+Alt+Tab.

С console.obj разбирайтесь сами. Я физически не имею времени разбираться во всем и исправлять все.

Кроме выше описанных проблем обнаружилась еще одна проблема - при пользовании mousemul управляющие клавиши (стрелки и 5) срабатывают на активном приложении. У меня нет идей как побороть эту ситуацию, если никто не предложит метод решения, то придется откатить ревизию 2611 и закопать мамонта обратно. Черт с ним с залипанием Shift, Ctrl, Alt - благими намерениями вымощена дорога сами знаете куда.

Интересно как в больших системах решают такие коллизии.