LINUX.ORG.RU

Русско-немецкая клавиатура в XFree86


0

0

В SuSE похоже проигнорировали мое предложение включить в дистр кроме русско-английской раскладки клавиатуры еще и русско-немецкую. Тем не менее насколько мне известно, среди германских русскоязычных линуксоидов проблема использования в качестве латиницы именно немецкой а не американской раскладки довольно актуальна. Потому я предлагаю мое собственное решение: раскладка deru встраивается в XFree на равных правах с остальными без всяких дополнительных костылей. Все пока сыро (делал только для себя). Дальнейшая поддержка в зависимости от Feedback.

>>> Подробности



Проверено: maxcom
Ответ на: комментарий от Finder

Finder'у: > На самом деле задача вовсе не так тривиальна как кажется. Проблема в том, что немецкая раскладка состоит из друх групп. Как в русском рус/лат, так в немецком нем/нем_AltGr. Требовалось добавить к этому делу еще третью группу - "рус", причем чтобы ротация производилась между 1й и 3й группами по кнпке смены раскладки, а между 1й и 2й - по AltGr.

Прошу прощения за назойливость, но не могли бы вы дать мне url, где можно почитать про разные группы немецких раскладок? С чем связана разница - с тем, что там должны быть какие-то дополнительные клавиши, которые нельзя объединить со стандартной латинской клавиатурой или просто с расположением клавиш (напр. кто-то печатает вслепую). Или поясните сами, если не слишком тяжко, но это наверное, лучше напрямую (ivans@isle.spb.ru).

ivans
()

2Ok. anonymous:
Для X вероятно лучше всего подвинуть группы в sbj на одну и
подправить переключатель. (вероятно это не повредит в любом
случае, хотя папа у Пети не силен в математике)
Консоль тут оффтопик. Завязывай с этим немедленно!

2ivans: Ну здрасьте! А как же АПЛОДИСМЕНТЫ?
Какой конфуз, ага.
По поводу урла ситуевина по-моему и у Паскаля описана.
(а Вы где сведения накопали?)
Да и самим не слишком тяжело:
key <AD01> { [ q, Q ],
[at],
[ Cyrillic_shorti, Cyrillic_SHORTI ] };

Тость Вам как гройу сразу ясно, что поведение клавиши <q> таково:
None: q
Shift: Q
AltGr: @
Помимо <q> существует еще целый набор клавиш, для которых
и выделена вторая группа.

Wotson
()

2Finder:
> Когда добьешь, закинь плс мне на мыло: oleksiy@rbg.informatik.tu-darmstadt.de

Ну по идее уже получил, да?

Wotson
()

2Finder:
В прынцЫпе могу в эрпээмчики закрутить, если оно надо канешна...

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

svu: setxkbmap - но это достаточно дорогое удовольствие, на ходу менять кодировки

1. Почему? Программа небольшая, запускается редко.
2. Можно(вероятно) написать постоянно визящую программу типа недавно обсуждавшейся, которая будет вместо запуска setxkbmap загружать ранее парсеные раскладки.

Я приблизительно так пользую english русский и укра&#1111;нську. Раскладки переключаются Shift+Win. Правда при этом сильно мигают окна(фокус скачет) - скорее всего проблемы GKB апплета или SawMill - но напрягает не сильно, ибо довольно редкая операция.

Действительно серьезная проблема пожалуй одна - на маленьких клавишах много символов не влезет:-)

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

1. Потому, что это запуск целой проги. Потому, что это перетряхивание всей конфигурации xkb на сервере и клиенте. И парсенье весьма непростых и немаленьких файлов. Да, на гигагерце это все незаметно. Но сам подход - крив.

2. Именно так нынче и делает kxkb. Да, это резко ускоряет общий процесс. Но идея - все равно кривая. Вместо того, чтобы довести до ума полноценное использование имеющихся 4-х групп - перегружать всю конфигурацию сервера.

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

2 wotson: > 2ivans: Ну здрасьте! А как же АПЛОДИСМЕНТЫ? Ватсон, так про АПЛОДИСМЕНТЫ ж вы писали, не я! :-)

> key <AD01> { [ q, Q ], > [at], > [ Cyrillic_shorti, Cyrillic_SHORTI ] }; Да, на это я напоролся, но вообще у меня это было единственное место, где клавиши конфликтовали. Но поскольку русская буква Й наклеилась в аккурат на @ и полностью её закрыла, то я почесав немного репу, решил, что без символа "параграф" я обойдусь и назначил @ над тройкой. Других запрещённых приёмов мне не понадобилось :-)

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

>и назначил @ над тройкой. Других запрещённых приёмов мне не понадобилось :-)

Еще есть фигурные и квадратные скобки, pipe, тильда. Неужели не нужно было?

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

> Еще есть фигурные и квадратные скобки, pipe, тильда. Неужели не нужно было?

Да нет, не нужно, они ни с чем не пересекаются. Как на клавиатуре нарисовано, так и расставил. Впрочем вру, чтобы не давить на altgr каждый раз, когда нужна тильда, я сдублировал её на клавишу с градусом (кружочком)

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

svu: "1...Но сам подход - крив"
Таки да - слегка кривоват. Зато работает без привязки к WM, и прочим.

svu: "2...Вместо того, чтобы довести до ума полноценное использование имеющихся 4-х групп"
"Ага, и маму в дом..." :-) копирайт Дядя Федор

Как насчет гибкости - вместо добавления раскладки в список используемых (и опционально - назначения хоткея:-}) будем генерировать файлики - для каждого набора языков, которыми пользуется пользователь:-}? Оцените количество таких наборов (что-то типа (N!/((N-4)!*4!)), если память опять не подводит:-)
Пожалуй лучше использовать группы для сложных языков(требующих много кнопок) - и набор перегружаемых раскладок(отдельная для каждого языка|алфавита).

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

DonkeyHot ★★★★★
()

ja wohl!!!! неплохо, неплохо.... ща заюзаем.... теперь только проблемы с шрифтами останутся....тк я не нашел, как одновременно использовать koi8-ru и немецекие спецсимволы. ?

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

1. Слегка или нет - это уж как измерять, в радианах или градусах. А про привязку к wm - полноценное и последовательное использование внутреннего механизма xkb не может никак зависеть от wm и прочих (это, пожалуйста, поясните). Другое дело, что существующая система _конфигурации_ xkb не реализует все возможности _архитектуры_. Поэтому приходится придумывать либо кривые решения на основе setxkbmap, либо кривые (в другую сторону) в обход стандартного конфигурационного репозитория xkb. Решение этой проблемы - во внедрении _одногрупповых_ раскладок с возможностью _произвольного_ склеивания (до 4-х). Предложено и внедряется в xfree Иваном Паскалем. Вот внедрит - будет хорошо (конечно, только тому меньшинству, которое умудряется обходиться 4-мя группами:)

2. Не очень понял, почему полноценное использование 4-х групп осложнит жизнь "дяди Федора"?

С одногруппными раскладками - не нужно никаких факториалов. Это был бы просто кошмар! Хотя, конечно, знание математики Вы продемонстрировали:)

Да, меняем не всю конфигурацию. Но можно ведь и без этого обойтись!

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

Кстати, пользуясь случаем, рекламная пауза. В моем gswitchit есть libxklavier, совершенно не зависимый от gnome. Лично мне сильно облегчает работу с xkb api. Заинтересованным - рекомендации лучших собаководов (если переходить на лица, в идеях либки есть рука Паскаля, да простит мне Иван сравнение с собаководами:)

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

>А про привязку к wm
Это у меня какие-то сбойные ассоциации:). Уже не помню о чем это. Приношу свои извинения.

Что до произвольного склеивания (до 4х или более) - почему бы не считать "склеиванием" определенную реакцию(перегрузку XKBMAP) програмки на определенное событие? Только потому, что XServer поменяет какую-то внутреннюю табличку?
Зато 1)нет ограничений на количество раскладок, 2) програмки сильно проще и уже существуют.

Про дядю федора - попытка запихнуть все в 4 группы чем то напоминает этот момент из известного мультфильма.

>Но можно ведь и без этого обойтись
Обойтись можно без многого. Стоит ли...

>за выпрямление кривых
Я как бы тоже не против прямых решений. Но именно перегрузка xkb кажется мне более прямой:-) - Похоже оба решения достаточно кривы, но мы на них смотрим c разных сторон(это я знание геометрии демонстрирую:-)

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

Перегрузка xkbmap отличается от склеивания принципиально. Потому как склеивание приводит к смене одного байтика (даже 2 битов:) внутри иксов. А перегрузка... ("поменяет внутреннюю табличку"). Да, ограничение на кол-во раскладок есть. Серьезное ли? Скольким из нас нужно больше 4 групп? Я, кстати, в форуме предлагал - провести на lor опрос на эту тему. maxcom проигнорировал:( Может, он здесь прочтет и прореагирует? Или кто-нибудь из лично знающих ему намекнет? Мне действительно интересно - стОит ли заморачиваться перегрузкой конфигурации в gswitchit - с учетом того, что грядут склеиваемые раскладки.

Существование программ - не аргумент вообще. Был бы прямой путь - были бы и проги для него. Сегодня есть только кривой - есть и проги для него. Кстати, большинство из них (единственное известное мне исключение - только kxkb, да и то еще не зарелизенный) просто запускают setxkbmap - без прекомпиляции и пр. Т.е. реально накладные расходы _существенно_ выше, чем смена 2 битов и даже больше, чем смена таблички...

Ну, ассоциацию про дядю Федора я понял, хотя и не разделяю. Да, архитекторы xkb не очень хорошо подумали (из серии "640k is enough for everyone" - хотя, может, в данном случае действительно доля людей, нуждающихся в >4 группах, пренебрежимо:) мала). Домик построили маленький. Но очень глупо строить деревню из таких домиков, если они почти пусты (и в большинстве случаев все население спокойно разместится в одном).

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

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

Теория относительности кривизны? :-))

Серьезно ли ограничение в четыре группы я не скажу - ибо я с грехом пополам могу использовать только 3 языка с коротким алфавитом каждый. Но вполне допускаю, что есть языки, которым одной группы мало. Представьте себе попытку написать что-то типа "grep" переводчиком с одного из таких языков на другой :)

Следует заметить, что перегрузка(против склеивания) довольно полно использует возможности архитектуры. Неполно она использует только зарезервированые элементы таблицы.

Что до критериев кривости - тут мы сталкиваеися с возможной кривизной архитектурных решений(=АР) и их(АР) применений:-). То есть кривизна в вашем определении - это кривизна _относительно_ АР. Предлагаю измерять кривизну относительно задачи - кривизна решения есть количество усилий, приложеных для удовлетворения реальных|вероятных потребностей(деленная на сложность задачи = величина для данной задачи постоянная).
При таком определении кривизна есть измеримая стоимость решения.
Если мы согласимся с этим определением, то (безотносительно кривизны XKB) ровнее всего - перегрузка XKB - этот вариант масштабируется гораздо легче и программы проще чем в случае склеивания таблиц.

Буду рад услышать более реальное определение кривости:)

DonkeyHot ★★★★★
()
Ответ на: Теория относительности кривизны? :-)) от DonkeyHot

Про случаи, когда именно 4-х групп мало, я придумать могу массу примеров. Например, украинец, переписывающийся с русскими и израильскими друзьями, работающий в немецкой фирме (сразу 2 группы). Так что фантазия у меня тоже есть:) Другое дело, сколько таких "переводчиков", "украинцев" и пр. (конечно, не в абсолютном - в процентном отношении). Если меньше 2 процентов - у меня есть сомнения, что я буду для них менять gswitchit...

Мое определение касалось кривизны применений АР (ПАР). Про сами АР я ничего не говорил (их кривизна - тема отдельной дискуссии). А кривизна ПАР - да, она зависит от АР. Я бы сказал - кривизна ПАР является нормой (корнем из квадратного отклонения) от духа и буквы АР. Мне кажется, это логично.

А относительно задачи и усилий измерять сложно. Тут вступают в дело такие трудноучитываемые и не относящиеся к делу факторы, как опыт пользователя, наличие софта (в данной системе и вообще в мире). Кроме того, Вы смешиваете кривизну с точки зрения пользователя и создателя пользовательских систем для настройки системы. Пользователю - все равно. Ему нужен только удобный интерфейс (а его можно сделать для любого подхода). Создателю систем - не все равно. Ему бы удобный API. Но такого сегодня почти нет (xkb api весьма велик и практически не документирован). Поэтому gkb вызывает setxkbmap - тупо и примитивно.

Хотя, наверное, кривизну АР можно измерять только от задачи. Но кривизна ПАР - только относительно к АР. Кстати, кривизну XKB как АР обсуждать будем?:)

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

Теория относительности кривизны? :-))

Сильно мне не нравится подход "а оставшиеся 1.5% пользователей нам не интересны". Особенно в случае если возможно решить все проблемы более простым(при том же API) способом.

Про кривизну договорились. Кривизну XKB обсуждать не стоит - оно достаточно для решения текущих задач - а разработка замены дорогое и (ввиду первого) ненужное дело.

Одно соображение - о букве и духе XKB: если языков больше 1 то их много. И уж ни в коем случае не 4. Следовательно логично было бы создавать спецификацию(XKB) либо (а)с неограниченым количеством групп либо (б) группы предназначались _не_ для реализации многоязыковых функций. Поскольку НЕ(а) и разработчики XKB думали, а не бросали кости(хочется верить), то должно быть (б). -> (кривее опять не то:-)

DonkeyHot ★★★★★
()
Ответ на: Теория относительности кривизны? :-)) от DonkeyHot

Про 1.5% - они мне интересны. Очень. Как исключение. Я их даже почти люблю и жалею:) Но вот захочу ли я тратить на них свое свободное время (в которое я разрабатываю gswitchit) - это вопрос. И я пока не уверен, что ответ на него положительный. Да, самый распространенный способ - он же самый простой. Но не эффективый. И, мне кажется, не соотв. духу и букве.

Теперь про дух и букву. Я не согласен с тем, что дух XKB выражен во фразе "если >1, то много". Читал доки по XKB - нет там такого. Если их больше 1 - до сколько угодно, но не больше 4-х ("640K is enough"). Иначе - большой и тяжелый труд по перегрузке конфигурации xkb. Про (а) и (б). Группы предназначались именно для многоязыковых функций. Иначе - просто не зачем. Потому как для всего остального есть shift levels, modifiers etc. И - посмотрите на раскладку ru - там именно 2 группы, русская и английская. Посмотрите также на раскладку en3 - очевидно, сделана для приклеивания английской _группы_. Так что тезис, что группы не для того - не подверждается фактами.

Однако, Вы неявно поставили вполне резонный вопрос - почему же тогда только 4. Попробую ответить. XKB разработан в SGI. В какой стране, знаете? Им даже сложно представить себе, зачем нужна вторая группа. А уж 4 им показалось вполне достаточно. А еще они соптимизировали что-то. Ну, было у них 2 свободных байта где-то - им и показалось, что достаточно. Не забывайте - XKB не был стандартизован никаким международным институтом (correct me if I am wrong). А американо-рожденные стандарты порой имеют подобные грешки (одна только битва за 8 бит чего стОит). "Internet is mostly American" и т.п. Такой мой ответ на Ваш вопрос.

Кстати, по поводу неограниченного числа групп. Кажется (может, ошибаюсь), в kxkb хотели сделать "правильно" - если групп <4, то только переключение группами, иначе - переходить в setxkbmap-like mode (возможно, опять же нарубая группы по 4). Может, я ошибаюсь про kxkb - но мне именно этот подход очень нравится. Более того, считаю его единственно правильным. Кстати, можно сделать api такое, чтобы прятать эту деталь (2-модовость). Пожалуй, так и сделаю в libxklavier - когда появятся комбинируемые раскладки в xfree.

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