info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Raspberry PI, Bullseye, переключение раскладок
14 views
Skip to first unread message
Maksim Dmitrichenko
Jan 24, 2022, 9:30:03 AM1/24/22
to
Всем привет!
Не совсем чистый Debian, но тем не менее. Купил ребенку Raspberry PI 400, водрузили на него свежий Raspberry PI OS, который на основе Bullseye сделан. Там Иксы и LXDE в качестве десктопа. Всё хорошо, кроме того, что если настроить переключение раскладки с En на Ru через их переключатель раскладок, как это рассказано в сотне статей и видеороликах, то переключение не работает. Точнее видно, что на долю секунды индикатор раскладки меняет свой флаг на российский, и потом обратно переключается на американский.
Кто-нибудь знает, как это преодолеть? Или хотя бы в какую сторону копать, чтобы найти виноватого? Сейчас даже не понимаю чья это вина: LXDE, xkb, x-сервера или кого-то ещё.
--
Не совсем чистый Debian, но тем не менее. Купил ребенку Raspberry PI 400, водрузили на него свежий Raspberry PI OS, который на основе Bullseye сделан. Там Иксы и LXDE в качестве десктопа. Всё хорошо, кроме того, что если настроить переключение раскладки с En на Ru через их переключатель раскладок, как это рассказано в сотне статей и видеороликах, то переключение не работает. Точнее видно, что на долю секунды индикатор раскладки меняет свой флаг на российский, и потом обратно переключается на американский.
Кто-нибудь знает, как это преодолеть? Или хотя бы в какую сторону копать, чтобы найти виноватого? Сейчас даже не понимаю чья это вина: LXDE, xkb, x-сервера или кого-то ещё.
With best regards
Maksim Dmitrichenko
Maksim Dmitrichenko
Victor Wagner
Jan 24, 2022, 10:00:04 AM1/24/22
to
В Mon, 24 Jan 2022 17:29:10 +0300
Maksim Dmitrichenko <dmit...@gmail.com> пишет:
Помнится у меня давно отстроенный LXDE внезапно перестал переключать
раскладки после установки Zoom из deb-пакета, скачанного с zoom.us.
Этот самый zoom потянул за собой ibus, а та перехватила переключалку
клавиатуры. Вылечилось это тыканьем в икогку ibus в tray и
категорическим запретом ей брать переключение раскладок на себя.
--
Victor Wagner <vi...@wagner.pp.ru>
Maksim Dmitrichenko <dmit...@gmail.com> пишет:
раскладки после установки Zoom из deb-пакета, скачанного с zoom.us.
Этот самый zoom потянул за собой ibus, а та перехватила переключалку
клавиатуры. Вылечилось это тыканьем в икогку ibus в tray и
категорическим запретом ей брать переключение раскладок на себя.
--
Victor Wagner <vi...@wagner.pp.ru>
Maksim Dmitrichenko
Feb 9, 2022, 3:50:02 PM2/9/22
to
Сам спросил, сам нашёл ответ. Во всем виноват оконный менеджер mutter: он перехватывает события смены раскладки через xkb и отменяет их. Единственным легитимным способом переключения раскладок он, кажется, считает вызов определённой функции в libmutter.
Пришлось закомментировать этот блок говнокада и пересобрать пакет. Потому что переключиться с mutter на openbox тоже с разбегу не вышло почему-то.
пн, 24 янв. 2022 г., 17:29 Maksim Dmitrichenko <dmit...@gmail.com>:
Max Nikulin
Feb 12, 2022, 10:00:02 AM2/12/22
to
On 10/02/2022 03:40, Maksim Dmitrichenko wrote:
> Сам спросил, сам нашёл ответ. Во всем виноват оконный менеджер mutter:
> он перехватывает события смены раскладки через xkb и отменяет их.
> Единственным легитимным способом переключения раскладок он, кажется,
> считает вызов определённой функции в libmutter.
Если правильно понимаю, то это последствие того, что в ubuntu когда-то
> Сам спросил, сам нашёл ответ. Во всем виноват оконный менеджер mutter:
> он перехватывает события смены раскладки через xkb и отменяет их.
> Единственным легитимным способом переключения раскладок он, кажется,
> считает вызов определённой функции в libmutter.
был патч, который позволял и раскладку переключать, например,
Ctrl+Shift, и эти же самые клавиши использовать в комбинациях с другими.
mutter 2857fdbdb8, где воткнули XkbLockGroup:
Ubuntu ships a patch in the X server that makes the group switch
keybindings only work on key release, i.e. the X server internal group
locking happens on key release which means that mutter gets the
XKB_KEY_ISO_Next_Group key press event, does its XLockGroup() call
with a new index and then, on key release, the X server moves the
index further again.
> Пришлось закомментировать этот блок говнокада и пересобрать пакет.
> Потому что переключиться с mutter на openbox тоже с разбегу не вышло
> почему-то.
https://bugzilla.gnome.org/show_bug.cgi?id=756543
Third-party keyboard switchers are not supported in GNOME. Plenty of
other XKB knobs/behaviors were already impossible or at least
impractical when set from outside mutter's control. That's a conscious
design decision that's not going to change unless there's a very good
case for it.
Как-то слишком радикально получилось у них приделать поддержку CJK.
Любопытно, есть ли в LXDE аналог вот такого крокодила, который
переключает раскладки в gnome?
gdbus call --session --dest org.gnome.Shell \
--object-path /org/gnome/Shell \
--method org.gnome.Shell.Eval \
"imports.ui.status.keyboard.getInputSourceManager().inputSources[1].activate()"
Maksim Dmitrichenko
Feb 12, 2022, 11:10:03 AM2/12/22
to
Если правильно понимаю, то это последствие того, что в ubuntu когда-то
был патч, который позволял и раскладку переключать, например,
Ctrl+Shift, и эти же самые клавиши использовать в комбинациях с другими.
Справедливости ради весь Xkb - это тоже одна большая помойка. Чё-то до сих пор помнится мне, что проблема с тем, что на русской раскладке комбинации с модификаторами приводили к тому, что генерировались Ctrl-Я вместо ожидаемого Ctrl-Z, ну и всё такое.
> Пришлось закомментировать этот блок говнокада и пересобрать пакет.
> Потому что переключиться с mutter на openbox тоже с разбегу не вышло
> почему-то.
Я решил, что от gnome лучше держаться подальше, когда прочитал вот такое:
Разделяю.
https://bugzilla.gnome.org/show_bug.cgi?id=756543
Third-party keyboard switchers are not supported in GNOME. Plenty of
other XKB knobs/behaviors were already impossible or at least
impractical when set from outside mutter's control. That's a conscious
design decision that's not going to change unless there's a very good
case for it.
Как-то слишком радикально получилось у них приделать поддержку CJK.
В целом, их тоже понять можно (см. выше).
Любопытно, есть ли в LXDE аналог вот такого крокодила, который
переключает раскладки в gnome?
gdbus call --session --dest org.gnome.Shell \
--object-path /org/gnome/Shell \
--method org.gnome.Shell.Eval \
"imports.ui.status.keyboard.getInputSourceManager().inputSources[1].activate()"
На сколько я успел разобраться в LXDE есть плагин Lxpanel, который отлавливает изменение раскладки и меняет флажок. Кроме того, он может отлавливать переключение окон и восстанавливаться раскладку для каждого окна. На этом все.
Max Nikulin
Feb 13, 2022, 6:50:03 AM2/13/22
to
On 12/02/2022 23:00, Maksim Dmitrichenko wrote:
> сб, 12 февр. 2022 г. в 17:55, Max Nikulin:
сомневаться, что это вообще возможно. Например, на экране 2 программы,
одна с русской локализацией, другая с английской. Русская ожидает
Alt+русская буква (хотя лично мне хочется странного: даже при русской
локализации работали бы английские комбинации, который на других
клавишах). Еще интереснее становится, когда доходит дело до Ctrl+, - с
какой раскладки брать запятую? Дополнительные символы на цифровых
клавишах в европейских раскладках могут быть переставлены...
С другой стороны, оставлять все на совесть разработчикам
программы/библиотеки/toolkit тоже так себе идея.
Gnome вроде следит, чтобы первой всегда стояла английская раскладка, а
нужная пользовательская - следующей группой. Так хотя бы нормальные
приложения могут определить, что Ctrl+Z и Ctrl+Я - одно и тоже, правда
ценой дополнительных усилий и потенциальных ошибок при реализации.
> Как-то слишком радикально получилось у них приделать поддержку CJK.
>
> В целом, их тоже понять можно (см. выше).
Главное, что мне не нравится, так это то, что оторвали возможность не
использовать активное переключение, а тихо сидеть и только менять значок
при смене раскладки. Оно, конечно, дополнительный код, за
работоспособностью которого надо следить, техподдержке каждый раз надо
спрашивать, а не включена ли такая галочка...
> На сколько я успел разобраться в LXDE есть плагин Lxpanel, который
> отлавливает изменение раскладки и меняет флажок. Кроме того, он может
> отлавливать переключение окон и восстанавливаться раскладку для каждого
> окна. На этом все.
Значок на панели обычно позволяет на него тыкать и переключать мышкой,
интересно, каким механизмом пользуется он.
Раз mutter взялся прибивать гвоздями группу xkb, то вроде за
восстановлением раскладки при переключении окон тоже должен следить
window manager, а не LXDE.
Ну и если в LXDE работает то, к чему стремились в Gnome (в какой степени
получилось - другой вопрос), то одного xkb мало, нужен еще кто-то,
возможно управляющийся по dbus, ну или ibus сам обрабатывает
переключения (но тогда он должен об этом рассказывать mutter). Были
слова о том, что раскладок может быть больше 4, поэтому переключать
группу мало, бывает нужно полностью переконфигурировать xkb на новые
группы. По факту в gnome получилось, что переконфигурация делается при
каждом переключении на пару en + нужная.
Я год назад немного поигрался с gnome и ibus (с последним отдельно от
gnome), но не нашел, как их заставить при включении input method
выбирать английский xkb layout, который этот метод ждет. Иероглифов я не
понимаю, поэтому пробовал на нотации LaTeX для специальных символов. У
input method может быть комбинация клавиш для его отключения, чтобы
пропускать в приложение исходные символы, то тогда это полностью
ортогонально раскладке, и индикаторов должно быть два: для метода ввода
и для раскладки xkb, а я видел только один.
> сб, 12 февр. 2022 г. в 17:55, Max Nikulin:
>
> Если правильно понимаю, то это последствие того, что в ubuntu когда-то
> был патч, который позволял и раскладку переключать, например,
> Ctrl+Shift, и эти же самые клавиши использовать в комбинациях с другими.
>
> Справедливости ради весь Xkb - это тоже одна большая помойка. Чё-то до
> сих пор помнится мне, что проблема с тем, что на русской раскладке
> комбинации с модификаторами приводили к тому, что генерировались
> Ctrl-Я вместо ожидаемого Ctrl-Z, ну и всё такое.
Я бы тоже хотел, чтобы такое работало из коробки, только вот начал
> Если правильно понимаю, то это последствие того, что в ubuntu когда-то
> был патч, который позволял и раскладку переключать, например,
> Ctrl+Shift, и эти же самые клавиши использовать в комбинациях с другими.
>
> Справедливости ради весь Xkb - это тоже одна большая помойка. Чё-то до
> сих пор помнится мне, что проблема с тем, что на русской раскладке
> комбинации с модификаторами приводили к тому, что генерировались
> Ctrl-Я вместо ожидаемого Ctrl-Z, ну и всё такое.
сомневаться, что это вообще возможно. Например, на экране 2 программы,
одна с русской локализацией, другая с английской. Русская ожидает
Alt+русская буква (хотя лично мне хочется странного: даже при русской
локализации работали бы английские комбинации, который на других
клавишах). Еще интереснее становится, когда доходит дело до Ctrl+, - с
какой раскладки брать запятую? Дополнительные символы на цифровых
клавишах в европейских раскладках могут быть переставлены...
С другой стороны, оставлять все на совесть разработчикам
программы/библиотеки/toolkit тоже так себе идея.
Gnome вроде следит, чтобы первой всегда стояла английская раскладка, а
нужная пользовательская - следующей группой. Так хотя бы нормальные
приложения могут определить, что Ctrl+Z и Ctrl+Я - одно и тоже, правда
ценой дополнительных усилий и потенциальных ошибок при реализации.
> Как-то слишком радикально получилось у них приделать поддержку CJK.
>
> В целом, их тоже понять можно (см. выше).
использовать активное переключение, а тихо сидеть и только менять значок
при смене раскладки. Оно, конечно, дополнительный код, за
работоспособностью которого надо следить, техподдержке каждый раз надо
спрашивать, а не включена ли такая галочка...
> На сколько я успел разобраться в LXDE есть плагин Lxpanel, который
> отлавливает изменение раскладки и меняет флажок. Кроме того, он может
> отлавливать переключение окон и восстанавливаться раскладку для каждого
> окна. На этом все.
интересно, каким механизмом пользуется он.
Раз mutter взялся прибивать гвоздями группу xkb, то вроде за
восстановлением раскладки при переключении окон тоже должен следить
window manager, а не LXDE.
Ну и если в LXDE работает то, к чему стремились в Gnome (в какой степени
получилось - другой вопрос), то одного xkb мало, нужен еще кто-то,
возможно управляющийся по dbus, ну или ibus сам обрабатывает
переключения (но тогда он должен об этом рассказывать mutter). Были
слова о том, что раскладок может быть больше 4, поэтому переключать
группу мало, бывает нужно полностью переконфигурировать xkb на новые
группы. По факту в gnome получилось, что переконфигурация делается при
каждом переключении на пару en + нужная.
Я год назад немного поигрался с gnome и ibus (с последним отдельно от
gnome), но не нашел, как их заставить при включении input method
выбирать английский xkb layout, который этот метод ждет. Иероглифов я не
понимаю, поэтому пробовал на нотации LaTeX для специальных символов. У
input method может быть комбинация клавиш для его отключения, чтобы
пропускать в приложение исходные символы, то тогда это полностью
ортогонально раскладке, и индикаторов должно быть два: для метода ввода
и для раскладки xkb, а я видел только один.
Maksim Dmitrichenko
Feb 14, 2022, 2:00:03 PM2/14/22
to
вс, 13 февр. 2022 г. в 14:45, Max Nikulin <mani...@gmail.com>:
Gnome вроде следит, чтобы первой всегда стояла английская раскладка, а
нужная пользовательская - следующей группой.
А зачем, допустим, немцам нужна английская раскладка вообще?
Так хотя бы нормальные
приложения могут определить, что Ctrl+Z и Ctrl+Я - одно и тоже, правда
ценой дополнительных усилий и потенциальных ошибок при реализации.
emacs по-моему не может.
Значок на панели обычно позволяет на него тыкать и переключать мышкой,
интересно, каким механизмом пользуется он.
Точно таким же, каким пользуется mutter - вызов XkbLockGroup().
Раз mutter взялся прибивать гвоздями группу xkb, то вроде за
восстановлением раскладки при переключении окон тоже должен следить
window manager, а не LXDE.
Так он и следит. Просто в его вселенной у всех приложения должна быть первая, потому что никто не переключал на другую его средствами. А mutter-совместимых средств переключения из коробки в Raspberry Pi OS нет.
Ну и если в LXDE работает то, к чему стремились в Gnome (в какой степени
получилось - другой вопрос), то одного xkb мало, нужен еще кто-то,
возможно управляющийся по dbus, ну или ibus сам обрабатывает
переключения (но тогда он должен об этом рассказывать mutter). Были
слова о том, что раскладок может быть больше 4, поэтому переключать
группу мало, бывает нужно полностью переконфигурировать xkb на новые
группы. По факту в gnome получилось, что переконфигурация делается при
каждом переключении на пару en + нужная.
Возможно мне кажется, но выглядит как лютый пипец. Причем, что самое возмутительное, это же самое дерьмо перетянули в Wayland. Хотя проектировали типа с нуля, и среди проектантов был один из трёх человек на Земле, который [якобы] действительно понимает как работает Xkb в иксах.
Развязка этой проблемы вообще оказалась возмутительной. Были сделаны два pull request'а в репо Raspberry OS и открыт issue. Всё это отвергнуто, потому что "в светлом будущем будет другой способ переключения раскладок, а этот не будет работать". Когда это будущее настанет не понятно (но явно не раньше релиза bookworm) и почему это время нужно ожидать без работающего механизма переключения раскладок - не понятно. Ну и да: переключение раскладок в Raspberry OS не поддерживается вообще - официально (!!!), потому что эра немого кино уже прошла, а звукового ещё не настала.
Это только цветных и геев нельзя дискриминировать. А весь остальной нелатиноалфавитный мир - да запросто!
Victor Wagner
Feb 15, 2022, 2:10:03 PM2/15/22
to
В Mon, 14 Feb 2022 21:49:50 +0300
Maksim Dmitrichenko <dmit...@gmail.com> пишет:
> Развязка этой проблемы вообще оказалась возмутительной. Были сделаны
> два pull request'а в репо Raspberry OS и открыт issue. Всё это
> отвергнуто, потому что "в светлом будущем будет другой способ
> переключения раскладок, а этот не будет работать". Когда это будущее
> настанет не понятно (но явно не раньше релиза bookworm) и почему это
> время нужно ожидать без работающего механизма переключения раскладок
> - не понятно. Ну и да: переключение раскладок в Raspberry OS не
> поддерживается вообще - официально (!!!), потому что эра немого кино
> уже прошла, а звукового ещё не настала.
>
> [1] https://github.com/raspberrypi-ui/lxpanel-bullseye/pull/4
> [2] https://github.com/raspberrypi-ui/mutter-bullseye/pull/1
> [3] https://github.com/raspberrypi-ui/lxpanel-bullseye/issues/3
> Это только цветных и геев нельзя дискриминировать. А весь остальной
> нелатиноалфавитный мир - да запросто!
Внимание, вопрос - а нафига ставить это гейское поделие, если на это
железо прекрасно ставится нормальный полноценный Debian?
Более того, когда buster еще был testing, я ставил его на Raspberry PI
3B и он у меня туда ставился 64-битный, в то время как Raspberry PI OS
еще 64-битной быть не умела.
Я уже примерно лет двадцать назад пришел к выводу, что если на данное
железо есть ОС от производителя железа, и есть ОС от компании или
сообщества, которое только софтом занимается, то надо ставить ОС от
чисто софтовой компании. Потому что те кто умеет железо, не умеют
софт. Ну и то же самое касается драйверов. Драйвер от производителя
железа будет глючить и виснуть. Драйвер от производиеля ОС - тормозитЬ,
но работать.
Последней фирмой, которая умела то и другое была Sun Microsystems.
IBM вот последнее время не особенно и пытается софт, предлагая на
свои сервера линуксы что для ppc, что для z390x.
--
Victor Wagner <vi...@wagner.pp.ru>
Maksim Dmitrichenko <dmit...@gmail.com> пишет:
> Развязка этой проблемы вообще оказалась возмутительной. Были сделаны
> два pull request'а в репо Raspberry OS и открыт issue. Всё это
> отвергнуто, потому что "в светлом будущем будет другой способ
> переключения раскладок, а этот не будет работать". Когда это будущее
> настанет не понятно (но явно не раньше релиза bookworm) и почему это
> время нужно ожидать без работающего механизма переключения раскладок
> - не понятно. Ну и да: переключение раскладок в Raspberry OS не
> поддерживается вообще - официально (!!!), потому что эра немого кино
> уже прошла, а звукового ещё не настала.
>
> [1] https://github.com/raspberrypi-ui/lxpanel-bullseye/pull/4
> [2] https://github.com/raspberrypi-ui/mutter-bullseye/pull/1
> [3] https://github.com/raspberrypi-ui/lxpanel-bullseye/issues/3
> Это только цветных и геев нельзя дискриминировать. А весь остальной
> нелатиноалфавитный мир - да запросто!
железо прекрасно ставится нормальный полноценный Debian?
Более того, когда buster еще был testing, я ставил его на Raspberry PI
3B и он у меня туда ставился 64-битный, в то время как Raspberry PI OS
еще 64-битной быть не умела.
Я уже примерно лет двадцать назад пришел к выводу, что если на данное
железо есть ОС от производителя железа, и есть ОС от компании или
сообщества, которое только софтом занимается, то надо ставить ОС от
чисто софтовой компании. Потому что те кто умеет железо, не умеют
софт. Ну и то же самое касается драйверов. Драйвер от производителя
железа будет глючить и виснуть. Драйвер от производиеля ОС - тормозитЬ,
но работать.
Последней фирмой, которая умела то и другое была Sun Microsystems.
IBM вот последнее время не особенно и пытается софт, предлагая на
свои сервера линуксы что для ppc, что для z390x.
--
Victor Wagner <vi...@wagner.pp.ru>
Maksim Dmitrichenko
Feb 16, 2022, 8:40:03 AM2/16/22
to
вт, 15 февр. 2022 г. в 22:03, Victor Wagner <vi...@wagner.pp.ru>:
Внимание, вопрос - а нафига ставить это гейское поделие, если на это
железо прекрасно ставится нормальный полноценный Debian?
Оно, наверное, прекрасно работает, если вы используете эту железяку как сервер. У меня же это по сути полноценный компьютер, и там уже важны дрова видео. Я особенно с этим не разбирался, но там какие-то блобы поставляются для видео, 3D и видеоускорения, которых в базом дебиане вроде как нету. Всё-таки Raspberry PI OS - это не совсем BolgenOS - там есть свои дополнительные пакеты. А если их не юзать, то это и так практически debian.
Victor Wagner
Feb 17, 2022, 3:20:03 AM2/17/22
to
В Wed, 16 Feb 2022 16:34:55 +0300
Maksim Dmitrichenko <dmit...@gmail.com> пишет:
> вт, 15 февр. 2022 г. в 22:03, Victor Wagner <vi...@wagner.pp.ru>:
>
> > Внимание, вопрос - а нафига ставить это гейское поделие, если на это
> > железо прекрасно ставится нормальный полноценный Debian?
> >
>
> Оно, наверное, прекрасно работает, если вы используете эту железяку
> как сервер. У меня же это по сути полноценный компьютер, и там уже
> важны дрова видео. Я особенно с этим не разбирался, но там какие-то
Насколько я понимаю, в mainline Debian видео там вполне поддерживается.
Может и более медленно будет работать, но менее глючно.
> блобы поставляются для видео, 3D и видеоускорения, которых в базом
> дебиане вроде как нету. Всё-таки Raspberry PI OS - это не совсем
> BolgenOS - там есть свои дополнительные пакеты. А если их не юзать,
> то это и так практически debian.
Ну вот как мы видим на примере переключения раскладок - не совсем.
Поэтому лучше ставить Debian и если уж совсем припрет, тащить в него
отдельные пакеты из vendor-специфик форков, не забывая выкидывать их
нахрен при ближайшем dist-upgrade.
>
--
Victor Wagner <vi...@wagner.pp.ru>
Maksim Dmitrichenko <dmit...@gmail.com> пишет:
> вт, 15 февр. 2022 г. в 22:03, Victor Wagner <vi...@wagner.pp.ru>:
>
> > Внимание, вопрос - а нафига ставить это гейское поделие, если на это
> > железо прекрасно ставится нормальный полноценный Debian?
> >
>
> Оно, наверное, прекрасно работает, если вы используете эту железяку
> как сервер. У меня же это по сути полноценный компьютер, и там уже
> важны дрова видео. Я особенно с этим не разбирался, но там какие-то
Может и более медленно будет работать, но менее глючно.
> блобы поставляются для видео, 3D и видеоускорения, которых в базом
> дебиане вроде как нету. Всё-таки Raspberry PI OS - это не совсем
> BolgenOS - там есть свои дополнительные пакеты. А если их не юзать,
> то это и так практически debian.
Поэтому лучше ставить Debian и если уж совсем припрет, тащить в него
отдельные пакеты из vendor-специфик форков, не забывая выкидывать их
нахрен при ближайшем dist-upgrade.
>
--
Victor Wagner <vi...@wagner.pp.ru>
Maksim Dmitrichenko
Feb 17, 2022, 3:50:03 AM2/17/22
to
чт, 17 февр. 2022 г. в 11:17, Victor Wagner <vi...@wagner.pp.ru>:
Ну вот как мы видим на примере переключения раскладок - не совсем.
Поэтому лучше ставить Debian и если уж совсем припрет, тащить в него
отдельные пакеты из vendor-специфик форков, не забывая выкидывать их
нахрен при ближайшем dist-upgrade.
И так, и не совсем так. Ничто не мешает мне отключить их субрепозиторий и перейти на голый Debian'овский LXDE. Но проблему с раскладками это не решит всё равно. Mutter в этой части одинаковый и там, и там. Можно, конечно, взять другой WM, типа openbox. Но его можно взять и в Raspberry PI OS.
Victor Wagner
Feb 17, 2022, 5:10:03 AM2/17/22
to
В Thu, 17 Feb 2022 11:44:05 +0300
Maksim Dmitrichenko <dmit...@gmail.com> пишет:
В Debian по-моему openbox с lxde ставится по умолчанию.
Во всяком случае когда я полтора года назад ставил Debian с нуля, так и
было.
--
Victor Wagner <vi...@wagner.pp.ru>
Maksim Dmitrichenko <dmit...@gmail.com> пишет:
Во всяком случае когда я полтора года назад ставил Debian с нуля, так и
было.
--
Victor Wagner <vi...@wagner.pp.ru>
Maksim Dmitrichenko
Feb 17, 2022, 9:50:03 AM2/17/22
to
чт, 17 февр. 2022 г. в 13:00, Victor Wagner <vi...@wagner.pp.ru>:
В Debian по-моему openbox с lxde ставится по умолчанию.
Во всяком случае когда я полтора года назад ставил Debian с нуля, так и
было.
Да. И там LXDE заброшенный на GTK2. Но зато переключалка работает =)
Max Nikulin
Feb 23, 2022, 7:40:02 AM2/23/22
to
On 15/02/2022 01:49, Maksim Dmitrichenko wrote:
> вс, 13 февр. 2022 г. в 14:45, Max Nikulin:
пользуются. У них может быть немного больше букв, чем у американцев, не
удивлюсь, что какие-то клавиши могут быть заняты, как в русской
раскладке нет фигурных скобок. Может быть, для написания кода
американская в некоторых случаях удобнее, потому что какие-нибудь 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). Но любопытства разбираться,
как они из него собирают пакеты, пока недостаточно.
> вс, 13 февр. 2022 г. в 14:45, Max Nikulin:
>
>> Gnome вроде следит, чтобы первой всегда стояла английская раскладка, а
>> нужная пользовательская - следующей группой.
>
> А зачем, допустим, немцам нужна английская раскладка вообще?
Честно говоря, ни разу не поинтересовался, какими раскладками европейцы
>> Gnome вроде следит, чтобы первой всегда стояла английская раскладка, а
>> нужная пользовательская - следующей группой.
>
> А зачем, допустим, немцам нужна английская раскладка вообще?
пользуются. У них может быть немного больше букв, чем у американцев, не
удивлюсь, что какие-то клавиши могут быть заняты, как в русской
раскладке нет фигурных скобок. Может быть, для написания кода
американская в некоторых случаях удобнее, потому что какие-нибудь dead
keys для акцентов не мешаются.
Кстати, у французов переставлены несколько кнопок: А вместо Q и т.д.
Если настроены французская и русская раскладки, то что должна отправлять
Ctrl+Й? А если пользователь добавил в кучу американскую? Это я к тому,
что на уровне Xkb логика может оказаться не очень простой.
>> Так хотя бы нормальные
>> приложения могут определить, что Ctrl+Z и Ctrl+Я - одно и тоже, правда
>> ценой дополнительных усилий и потенциальных ошибок при реализации.
>
> emacs по-моему не может.
что немного надорвались, втаскивая часть unicode data для письма справа
налево.
Раскладку ему приходится прибивать гвоздями и пользоваться его input
method. Попадалось, что события переключения раскладок к нему не
пропускает Gtk. Дальше там вроде экономили биты для хранения событий
клавиатуры (могу ошибаться), то есть информацию о раскладке тоже просто
так не добавишь. Ну и код на том уровне должен работать уже не только с
Xkb, но и на всяких Windows. Видел пакет, который слушает dbus, чтобы
понять, что переключилась раскладка. А в терминале становится еще
веселее, Xkb остается на уровне окошка этого самого терминала. Не знаю,
можно ли спастись чем-нибудь типа input-decode-map, но опять же как
спрашивать про текущую раскладку.
>> Значок на панели обычно позволяет на него тыкать и переключать мышкой,
>> интересно, каким механизмом пользуется он.
>
> Точно таким же, каким пользуется mutter - вызов XkbLockGroup().
что я запутался и ничего не понял. Я бы ожидал, что 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 нет.
не первой, а mutter держит ту, про которую ему явно рассказали. Вот кто
это вообще делает в LXDE?
> Возможно мне кажется, но выглядит как лютый пипец. Причем, что самое
> возмутительное, это же самое дерьмо перетянули в Wayland. Хотя
> проектировали типа с нуля, и среди проектантов был один из трёх человек на
> Земле, который [якобы] действительно понимает как работает Xkb в иксах.
Wayland? Острой необходимости искать самому пока не было. С первого
взгляда показалось, что для описания раскладок там используются те же
самые файлы, что и в Xkb.
> Развязка этой проблемы вообще оказалась возмутительной. Были сделаны два
> pull request'а в репо Raspberry OS и открыт issue. Всё это отвергнуто,
>
Я бы тоже сопротивлялся, если бы увидел патчи в таком виде. Maintainer
же, скорее всего, не знает всю эту историю про проблемы xkb и mutter.
Либо прямо в коде, либо в commit message должно быть пояснение, при
каких условиях патч можно будет выкинуть. Не хватает объяснения, почему
риск от такого патча небольшой: никому мешать не должен, он убирает
изменение, добавленное, чтобы бороться с другим патчем, которого уже
давно нет (со ссылками на коммит и bug report). Upstream его может
держать ради дистрибутивов, которые до сих пор собирают xkb c патчем для
Ctrl+Shift переключателей. Можно попытаться убедить словами, нужна не
столько официальная поддержка переключения раскладок, сколько
возможность переключать ее вообще. Mutter станет более прозрачным для
переключения средствами Xkb. Вот поддерживать раскладку для каждого
окна, скорее всего, не сможет. Человек, увидевший патч через несколько
лет, должен понять кому, почему и при каких условиях этот патч помогает.
А вообще репозиторий mutter у raspberryPy немного странный. Это и не
репозиторий с локальными патчами, и не клон с полной историей
(начинается с импорта исходников debian). Но любопытства разбираться,
как они из него собирают пакеты, пока недостаточно.
0 new messages