Re: Raspberry PI, Bullseye, переключение раскладок

[Max Nikulin <manikulin@gmail.com>]

On 15/02/2022 01:49, Maksim Dmitrichenko wrote:
> вс, 13 февр. 2022 г. в 14:45, Max Nikulin:
>
> > Gnome вроде следит, чтобы первой всегда стояла английская раскладка, а
> > нужная пользовательская - следующей группой.
>
> А зачем, допустим, немцам нужна английская раскладка вообще?

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

Кстати, у французов переставлены несколько кнопок: А вместо Q и т.д. 
Если настроены французская и русская раскладки, то что должна отправлять 
Ctrl+Й? А если пользователь добавил в кучу американскую? Это я к тому, 
что на уровне Xkb логика может оказаться не очень простой.

> > Так хотя бы нормальные
> > приложения могут определить, что Ctrl+Z и Ctrl+Я - одно и тоже, правда
> > ценой дополнительных усилий и потенциальных ошибок при реализации.
>
> emacs по-моему не может.

Ну у emacs с локализацией вообще очень неравномерно. Создалось ощущение, 
что немного надорвались, втаскивая часть unicode data для письма справа 
налево.

Раскладку ему приходится прибивать гвоздями и пользоваться его input 
method. Попадалось, что события переключения раскладок к нему не 
пропускает Gtk. Дальше там вроде экономили биты для хранения событий 
клавиатуры (могу ошибаться), то есть информацию о раскладке тоже просто 
так не добавишь. Ну и код на том уровне должен работать уже не только с 
Xkb, но и на всяких Windows. Видел пакет, который слушает dbus, чтобы 
понять, что переключилась раскладка. А в терминале становится еще 
веселее, Xkb остается на уровне окошка этого самого терминала. Не знаю, 
можно ли спастись чем-нибудь типа input-decode-map, но опять же как 
спрашивать про текущую раскладку.

> > Значок на панели обычно позволяет на него тыкать и переключать мышкой,
> > интересно, каким механизмом пользуется он.
>
> Точно таким же, каким пользуется mutter - вызов XkbLockGroup().

А вне RaspberryPi это тогда вообще работает? Запросто может оказаться, 
что я запутался и ничего не понял. Я бы ожидал, что gnome-shell каким-то 
образом дергает за ручки mutter объясняя ему, какая раскладка текущая, а 
без gnome-shell это должна делать другая специальная утилита. Только не 
могу понять, как связаны вызовы set_keymap и lock_layout_group в 
gnome-shell/js/misc/keyboardManager.js и методы из 
mutter/src/backends/x11/cm/meta-backend-x11-cm.c

> > Раз mutter взялся прибивать гвоздями группу xkb, то вроде за
> > восстановлением раскладки при переключении окон тоже должен следить
> > window manager, а не LXDE.
>
> Так он и следит. Просто в его вселенной у всех приложения должна быть
> первая, потому что никто не переключал на другую его средствами. А
> mutter-совместимых средств переключения из коробки в Raspberry Pi OS нет.

Я могу заблуждаться, но мне показалось, что в Gnome раскладка может быть 
не первой, а mutter держит ту, про которую ему явно рассказали. Вот кто 
это вообще делает в LXDE?

> Возможно мне кажется, но выглядит как лютый пипец. Причем, что самое
> возмутительное, это же самое дерьмо перетянули в Wayland. Хотя
> проектировали типа с нуля, и среди проектантов был один из трёх человек на
> Земле, который [якобы] действительно понимает как работает Xkb в иксах.

А нет ли ссылки с внятным описанием, как работа с клавиатурой устроена в 
Wayland? Острой необходимости искать самому пока не было. С первого 
взгляда показалось, что для описания раскладок там используются те же 
самые файлы, что и в Xkb.

> Развязка этой проблемы вообще оказалась возмутительной. Были сделаны два
> pull request'а в репо Raspberry OS и открыт issue. Всё это отвергнуто,
>
> [2] https://github.com/raspberrypi-ui/mutter-bullseye/pull/1

Я бы тоже сопротивлялся, если бы увидел патчи в таком виде. Maintainer 
же, скорее всего, не знает всю эту историю про проблемы xkb и mutter. 
Либо прямо в коде, либо в commit message должно быть пояснение, при 
каких условиях патч можно будет выкинуть. Не хватает объяснения, почему 
риск от такого патча небольшой: никому мешать не должен, он убирает 
изменение, добавленное, чтобы бороться с другим патчем, которого уже 
давно нет (со ссылками на коммит и bug report). Upstream его может 
держать ради дистрибутивов, которые до сих пор собирают xkb c патчем для 
Ctrl+Shift переключателей. Можно попытаться убедить словами, нужна не 
столько официальная поддержка переключения раскладок, сколько 
возможность переключать ее вообще. Mutter станет более прозрачным для 
переключения средствами Xkb. Вот поддерживать раскладку для каждого 
окна, скорее всего, не сможет. Человек, увидевший патч через несколько 
лет, должен понять кому, почему и при каких условиях этот патч помогает.

А вообще репозиторий mutter у raspberryPy немного странный. Это и не 
репозиторий с локальными патчами, и не клон с полной историей 
(начинается с импорта исходников debian). Но любопытства разбираться, 
как они из него собирают пакеты, пока недостаточно.