"Ночные" сборки KolibriOS

Sun Sep 11, 2011 8:37 pm

С ревизии 2171 поведение CAPS LOCK для режима ASCII кодов стало как в нормальных системах, т.е. при включенном CAPS LOCK генерируются заглавные буквы, если нажать еще и SHIFT, то маленькие. Во всех программах вроде работает нормально, по крайней мере в KEYASCII и использующих EditBox. Исключением является Tinypad - который каким-то образом игнорирует.

UPD. Оказывается Shell тоже ведет себя как Tinypad.

Sun Sep 11, 2011 11:04 pm

Mario wrote:UPD. Оказывается Shell тоже ведет себя как Tinypad.

Завтра после работы гляну код шелла.

В принципе, теперь можно попробовать раскомментировать условно-компилируемый блок приложения @panel. При нажатом CapsLock аббревиатуры языков пишутся заглавными буквами, при отжатом - строчными. Ну, чтобы потестировать...

Mon Sep 12, 2011 2:38 am

Тинипад исправил, все дело в ~~волшебных пузырьках~~ сканкодах. Пришлось вручную обработку выписывать. Код не сложный, но пока нашел куда воткнуть - кучу времени потратил. Может и в Shell сканкоды вместо ASCII, но я не раскурю ЯВУ код.

Mon Sep 12, 2011 7:12 am

Не дождался вечера, глянул... В принципе, исправить можно. Нужно написать 2 маленькие функции и в основной код вставить 2 строчки с if-ом...

Mon Sep 12, 2011 3:39 pm

Сюрприз: обработкой ввода в консольных приложениях, включая shell, занимается консоль console.obj.

Разве не проще включить поддержку CapsLock на уровне системы, инвертируя флаг нажатости Shift при включённом CapsLock? При этом не понадобится в каждой программе писать одно и то же.

Mon Sep 12, 2011 3:59 pm

Так ведь оно так и сделано, но для режима сканкодов так не сделаешь - в этом случае начнут ложно срабатывать служебные комбинации клавиш. Если программа вроде Тинипада сама разбирает сканкоды и подставляет нужные раскладки, то приходится пилить программу именно. Насчет того что собака зарыта в console.obj у меня была мысль, но до конца уверенности не было.

Mon Sep 12, 2011 4:05 pm

Почему? Программа должна определить состояние Shift через 66.4, что мешает инвертировать биты, отвечающие за Shift, при нажатом CapsLock?

Mon Sep 12, 2011 4:10 pm

И будет срабатывать run в doom при нажатом caps lock? (Точнее наоборот, не будет)

Mon Sep 12, 2011 4:23 pm

CleverMouse wrote:Почему? Программа должна определить состояние Shift через 66.4, что мешает инвертировать биты, отвечающие за Shift, при нажатом CapsLock?

Дело не в горячих клавишах. Для примера посмотри как сделано в \programs\develop\tinypad\trunk\tp-key.asm

Mon Sep 12, 2011 4:26 pm

Mario, я ошиблась на единицу, я имела в виду 66.3.
Sorcerer, в одном приложении, в котором важен именно Shift, а не CapsLock+Shift, можно и дописать код - это лучше, чем дописывать код во все приложения, кроме одного.

Mon Sep 12, 2011 4:39 pm

Опять же ты не до конца понимаешь - некоторые приложения отлавливают комбинации клавиш вручную и для них зажатый флаг SHIFT (при помощи кода от CAPS LOOK) приведет к разнообразным ненужным эффектам. Как раз в твоем предложении придется дописывать кучу программ.

Mon Sep 12, 2011 4:43 pm

Некоторые программы ведь отлавливают caps lock как самостоятельную клавишу. Вариант с включением shift по caps, например, не подходит для переключателя раскладки по caps lock (и хотя это извращение, как мне кажется, есть люди, которые caps lock именно так и используют). Или я чего-то не понимаю?

Mon Sep 12, 2011 5:27 pm

Тезис номер 1: программ, которые используют сигнал о Shift для того, чтобы выяснить, нужно ли переводить символ в верхний регистр, заметно больше, чем программ, которые используют сигнал о Shift для других целей.
Тезис номер 2: при инвертировании сигнала о Shift при нажатом CapsLock по-прежнему можно узнать, действительно ли нажата Shift, на это всего лишь уйдёт несколько больше кода.
Тезис номер 3: изменения в программах иногда ломают существующий функционал, поэтому при прочих равных условиях количество изменений желательно сводить к минимуму.
Если вы согласны с тезисами, то должны согласиться и с выводом.
Вывод: желательно инвертировать сигнал о Shift при нажатом CapsLock, поскольку это уменьшает число необходимых изменений.

Mon Sep 12, 2011 5:58 pm

Тезис 1 не основан на реальных цифрах. На самом деле большинство программ используют ASCII код и уже нормально отрабатывают. Меняя реальные показатели функции 66.3 мы создаем искусственную реальность. Пока что я вижу только программы использующие console.obj - исправить ситуацию в библиотеке и все.
Тезис 2 - как? Вводить еще одну подфункцию? Или отлавливать коды всегда?
Тезис 3 - вообще голословен, иногда и град случается.
С выводом не согласен. Нужно оперировать реальной ситуацией, а мы получается опять костылечек приделываем.

Mon Sep 12, 2011 6:07 pm

1. Я ничего не говорила о программах, использующих ASCII, не надо подменять понятия. Помимо консоли - тот же tinypad и kfar - это уже три примера.
2. Так же, как сейчас предлагается учитывать CapsLock программам, которым он нужен.
3. Следовательно, если ты настолько могущественный, что можешь выбирать между двумя вариантами поведения, отличие между которыми в том, что в одном случае град будет, а в другом - нет, выбирай второй.
Я так понимаю, костылями ты называешь всё, что тебе не нравится?

"Ночные" сборки KolibriOS

Who is online