OberonCore

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

Расширение клавиатуры

• использование кнопки-модификатора, в роли которой может выступать пробел или новая кнопка возле пробела, удерживаемая большим пальцем
• использование отдельных кнопок для включения разных раскладок вместо циклического переключателя, и создание навыка постоянно нажимать эти кнопки в начале ввода текста
• педаль и отдельная клавиатура для РЯ
• переключатель вместо кнопки, подвинул влево-вправо - получил разные языки
• vi - образное управление, при котором переход в режим команд - это одна кнопка, а перевод в режим
  ввода производится разными кнопками, в зависимости от языка. Сами кнопки включения режима ввода текста
  во вводе текста не участвуют (в отличие от собственно vi).

Индикация

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

Коррекция

• по образцу punto switcher - есть контрпример END = УТВ
• ввод транслитом и отдельная команда "переведи последнее слово из транслита и переключись в режим ввода русского текста"

Поскольку на этом форуме автор не может долго редактировать заглавие темы, я буду пополнять результаты темы здесь:
http://вече.программирование-по-русски.рф/viewtopic.php?f=2&t=224

Что тут думать?
Читал книгу по интерфейсам. Там говорилось, что проблемой являются различные режиме в софте. Люди часто забывают, как они вошли в этот режим, забывают, что они находятся в каком-то специальном режиме и могут не знать, как из него выйти. И как решение говорится, что люди не забывают то, о чем они получают мышечный отклик. То есть, если, допустим, для ввода на английском языке надо будет удерживать специальную кнопку (или педаль), то человек не забудет, что сейчас он вводит на английском. А в остальных случаях ввод будет на русском. Как-то так.

Вообще-то яроклава (http://программирование-по-русски.рф/яроклава-js.яргт/) именно так и сделана - нужно удерживать пробел для ввода латиницы. Но я ещё хочу сделать ви-образное управление во всей ОС. Тогда появляется, как минимум, два переключателя - команды/текст и рус/англ. У человека недостаточно пальцев, чтобы на каждый возможный режим занимать по целому пальцу. Я эту проблему уже осознал, а вот как её решить? Думаю, всё же решается она индикацией, в виде той самой рамочки вокруг экрана или цвета фона.

Shift можно нажимать и при слепом методе набора, то одной рукой, то другой рукой. Также можно специальную кнопку с двух сторон разместить.

А большие буквы куда же?

В целом дополнительная индикация через указатель мыши не помешает, но обычно при работе с клавиатурой на мышку не смотришь.

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

Вроде бы ещё цвет каретки курсора рассматривался, который, всё же, может быть слабо различимый (если форма каретки аля вертикальная черта). В дополнение, если в системе для текстовых виджетов (поля ввода) есть подсветка границ активного выбранного элемента, то также можно менять цвет у рамки выделения в зависимости от языка (вместе с кареткой).
Для крупных текстовых областей (аля текстовый редактор) можно разноцветно отмечать левую границу, как, напр. в JEdit (древний, уже малоизвестный, "эмакс на Java"):
http://www.jedit.org/index.php?page=screenshot&image=18

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

Скорее, не вместо стандартного циклического переключателя, а в дополнение (что актуально при использовании нескольких языков, напр., лев. shift включает английский, прав. -- восстанавливает предыдущий язык). И нажатие перед началом ввода, в основном, желательно после некоторой паузы (при интенсивной работе как-то ориентируешься, какой сейчас активный язык).

Также не помешают помогалки как тот же ввод через пробел, напр., при кириллице "пробел-х/ъ" -- ввод квадратных скобок, "пробел-9/0" -- фигурных и пр.

Чёт-то непонятна идея. Переход в режим ввода сам по себе может быть различным (через "a", "i", с вариацией через Shift, а также всякие плагины/расширения могут перекидывать на ввод после своих манипуляций).

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

Коллеги, я сделал каретку красного цвета для русского языка, предлагаю попробовать:
https://forum.oberoncore.ru/viewtopic.php?f=24&t=6577
Пока чот обратной связи никакой не было.

По моему опыту, цвет каретки заметен всегда, поскольку именно на каретку фокусируется взгляд. Это, кмк, выгодно отличало бы такую подсветку от рамки вокруг экрана, которая, действительно на периферии при большом мониторе. Впрочем, я не пробовал сделать рамку, поэтому "наощупь" не знаю, как будет. В стародавние времена дос-русификаторов, да, была хорошо заметная зеленая рамка; но 1) монитор был всего 14" (если повезет:) и 2) ДОС не страдал многозадачностью, поэтому ты сидел спокойненько в Лексиконе и набирал спокойненько текст, чаще всего моноязычный, никуда не переключаясь и не отвлекаясь. (Хотя нет, были в лексиконе "окна" с 1 по 9

Толщину каретки в ББ можно увеличить для заметности. Если фича зайдет, можно сделать и позаметнее каретку - как была в Обероне, напр, в виде стрелки |\.

Индикация на указателе мыши, кмк, не выигрышна, поскольку 1) мышь и каретка - в разных местах, поэтому придется глазами искать мышь; это еще неудобнее, чем индикатор в углу - поскольку индикатор всегда в одном месте, искать не надо, только перемещать взгляд.
2) индикатор гасится в некоторых системах после периода бездействия мыши.

Да, модальный должен не зависеть. С режимом и мне тоже непонятно. Т.е. пожелания есть, а как их выполнить - не совсем ясно.
Как вариант, уменьшить количество способов входа в режим ввода. Улучшить индикацию, чтобы после программного переключения режим был сразу виден.

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

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

http://вече.программирование-по-русски.рф/viewtopic.php?f=2&t=224&p=1266#p1266

В принципе то, обыграть нюансы с кареткой кое-как можно.

Например, вот здесь каретка специально подсвечена "очень горячей", чтобы была заметна:
https://cloud.githubusercontent.com/assets/175716/20177362/a9976398-a74c-11e6-955d-df029c7b329b.png

Это картинка из AceJump для IntelliJ (вариация режима передвижений из Эмакса). Так в некоторые моменты каретка "усиливается" (в данном случае чтобы наблюдать исходную позицию при одновременном осмотре целевого назначения и т.п.). Аналогично "горячей" каретка может быть, когда окно неактивно, при активации окна каретка возвращается в нормальный режим чуть с опозданием, или же становится какой-то менее "яркой" пока не начнётся работа с клавиатурой.

К примеру, в случае некоего режима поиска текста ввод символов может осуществляться в поле ввода где-то внизу экрана, в это поле даже не смотришь (где каретка), внимание остаётся на выделении текста по ходу поиска. Sublime, напр., может симпатично оформлять выделение -- чуть закруглённые углы (что полезно при возникновении всяких "ломанных" областей), а также выводить и цветовую рамку:
https://i.stack.imgur.com/7ISNn.png

Сама каретка может быть в виде рамки, например, в случае модального (normal) vi-режима. Такие же рамки могут быть и при специализированных выделениях, имеющих собственный фон как подсветка меток AceJump выше.


А так, в общем то, может возникнуть и "перегруз" в цветах и "визуальная зашумленность". В любом случае ещё необходим "ввод транслитом и отдельная команда "переведи последнее слово из транслита и переключись в режим ввода русского текста", т.к. косяки неизбежны иногда. Однако, в идеале необходима кнопка как аналог режима "undo" для текста: нажал и исправилось некоторое последнее введенное содержимое (как аналог отмены части последних операции), если необходимо -- ещё раз нажал и т.д. Но для такого необходима универсальная и "интеллектуальная" тесная интеграция механизма "ретранслита" с элементами системы.

В связи с установкой новой Debian попробую использовать CapsLock/Shift+CapsLock для переключения режимов.

В рамках Яос реализовал (почти) полный комплект возможностей
и особенностей, нужных для работы с двухъязычными текстами:

• яро-раскладка, т.е. ввод латиницы при удерживаемом пробеле
• отключаемый режим подчёркивания всей латиницы на экране
• шрифт, в котором латиница отличается по виду от кириллицы
• форма курсора показывает, какая раскладка клавиатуры включена

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

Также есть недоделки по индикации раскладки курсором - в маленьких текстовых полях
она не работает, исправить легко.

Но на уровне прототипа всё уже вполне сделано и рассчитываю прямо с этим работать.

Лайк!

Попробовал режим перечёркивания белым отличающихся букв латиницы, получилось вот так (см. рис 1)

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

После этого ещё раз попробовал улучшить режим подчёркивания - ограничил его только одинаковыми по начертанию буквами, постарался выровнять полоски по ширине и высоте (по высоте выравнивание работает только для моноширинных шрифтов) и сделал их поуже. Но он всё равно мне не нравится - работать с текстом в латинице в этом режиме совсем неудобно. Т.е. эти подчёркивания сильно загрязняют текст.



Может быть, нужно всё же действовать умнее и подчёркивать только смену языка внутри слова или внутри текста. Это гораздо более сложный функционал, я даже не уверен, что это оберон-вей, потому что возникают вопросы типа "а что делать в начале страницы".

Тем не менее, сейчас остановлюсь на варианте с подчёркиванием. На уровне понятий он показывает, как это работает. Для текстов с преобладанием кириллицы дискомфорта нет, просто пока в Яос доминирует латиинца. Будет стимул быстрее работать

Эксперименты со смешанными шрифтами отложу из-за их большой трудоёмкости, а шрифт всё же постараюсь сделать на базе DeJaVu. Правда, я начинаю думать, что шрифт с засечками лучше, несмотря на то, что он сейчас не в моде.

А "родные" шрифты Oberon и Syntax вы не рассматриваете?

А там разве есть кириллица? И они truetype? Желательно, чтобы шрифт всё же поддерживал разные юникодные значки, например, мне нужны кавычки, принятые в России, лапки и ёлочки. И они есть далеко не во всех шрифтах.

Вот ещё один вариант. Останется либо он, либо режим подчёркивания. Этот режим менее раздражающ, чем режим подчёркивания и думаю, что смогу им без душевных страданий пользоваться постоянно. Режим подчёркивания можно включать только на время, потом он начинает бесить. Т.е. он годится не для предотвращения ошибок, а лишь для их поиска, когда есть подозрение, что ошибка уже случилась.

Время покажет, какой окажется лучше.

На разработку шрифта сейчас нет времени (в соседней теме то же написал), хотя в целом разработать всё же нужно.