KUbuntu 22.04.1, a entrada chinesa fcitx não pode ser acionada imediatamente

Primeira vez usando KUbuntu (22.04.1 LTS); costumava usar Mate & Lubuntu antes, que minha fcitxentrada em chinês estava funcionando bem. No entanto,

Com o KUbuntu 22.04.1 LTS, minha fcitxentrada em chinês não está funcionando imediatamente - simplesmente não consigo acioná-la.

Aqui está a prova de que fcitxa instalação da minha entrada chinesa está bem.

• Na inicialização do meu KUbuntu 22.04.1, existem três fcitxprocessos relacionados (identificados por ps -eaf --width 200 | grep [f]citx):
  • /usr/bin/dbus-daemon --syslog --fork --print-pid 5 --print-address 7 --config-file /usr/share/fcitx/dbus/daemon.conf
  • /usr/bin/fcitx-dbus-watcher unix:abstract=/tmp/dbus-tW4A6FKmPk,guid=e64c862b67b86932863ee75863f14a15 5504
  • fcitx
• Se eu matar todos eles um por um, então comece fcitxnovamente manualmente,
  LANG=zh_CN.utf8 urxvt -ls &
  então está tudo bem. A tecla de atalho de acionamento está funcionando novamente.

ATUALIZAÇÃO: -- Há também um IBus Pannelícone na minha barra de tarefas do KUbuntu 22.04.1 quando ele inicia, e eu tenho que fazer quitisso manualmente toda vez após a inicialização.

Isso me faz suspeitar que o fcitxiniciado pelo meu KDE tem a configuração errada, o que estou tentando corrigir. (Meu ambiente de trabalho normal (desktop) é inglês, usando LANG=C. O fcitxé usado apenas para/com quaisquer aplicativos iniciados em/com o ambiente LANG='zh_CN.utf8', como rxvt-unicode, chrome, etc.)

Como corrigi-lo? por favor ajude.

$ im-config -m
default
missing
ibus

ibus

$ LANG=C im-config -m
default
missing
ibus

ibus

$ LANG=C im-config -m | tail -3 | hexdump -C
00000000  69 62 75 73 0a 0a 69 62  75 73 0a                 |ibus..ibus.|

$ LANG='zh_CN.utf8' im-config -m
default
missing
ibus
fcitx5
ibus

ATUALIZAÇÃO final:

Rastreei o motivo principal pelo qual tenho o ibus e o fcitx instalados. Aqui está porque é uma má ideia primeiro:

A razão pela qual tenho os dois métodos de entrada instalados é por causa do que zoompreciso usar e, a partir dessas duas páginas, posso ver que tal requisito é realmente desnecessário:

1. Dependência irritante do ibus em arquivos .deb de zoom
2. O pacote Zoom Debian Linux requer ibus mesmo no KDE e XFCE

Aqui estão algumas citações:

• Os arquivos .deb para download do zoom vêm com ibus no campo “Depende:”. Esse é um problema para muitos usuários do Debian/Ubuntu, e tentarei explicar o porquê.
• Escusado será dizer que estou muito desapontado com a forma como o Zoom respondeu ao meu pedido até agora.
• Estou trabalhando na manutenção de uma ferramenta (im-config) utilizada no Debian e no Ubuntu para facilitar a configuração dos métodos de entrada, por exemplo, IBus. É nessa função que recebi reclamações sobre a dependência do ibus no arquivo Zoom .deb, e é nessa função que estou aqui.
• Este é [email protected] (meu endereço de contato oficial do Debian) que é um membro central da manutenção do pacote ibus para o Debian. (Gunnar também é outro membro principal. Ele está fortemente envolvido no lado do Ubuntu.)
• Seu pedido não é um mero “pedido do usuário”. Isso deve ser considerado uma exigência das distribuições GNU/Linux ao ZOOM.
• Se o Zoom fornecer pacotes para Debian/Ubuntu (deb-packages) com conteúdo tecnicamente sólido, o ZOOM deve nos ouvir.
• Alguma atualização sobre isso? Acabei de instalar o zoom e consegui isso também. Essa dependência é irritante e inútil
• Essa desculpa para “controle remoto em uma máquina remota” é pateticamente carente de compreensão de como o campo “Dependes:” deve ser usado para o pacote Debian. Isso deve ser usado apenas para pacotes necessários em todos os ambientes de instalação. Fazer isso para um ambiente específico é considerado engenharia grosseira.
• Sou um desenvolvedor Debian e, portanto, estou familiarizado com as convenções e requisitos para pacotes Debian, também conhecidos como arquivos “.deb”. Conforme definido atualmente, a maneira como os pacotes Zoom Debian usam campos de relacionamento (como Depends:) viola a política de empacotamento Debian, descrita aqui: 7. Declarando relacionamentos entre pacotes — Manual de Política Debian v4.6.1.1

No entanto, todos os pedidos caem em ouvidos surdos e 1 mês depois, "Este tópico foi fechado automaticamente 30 dias após a última resposta. Novas respostas não são mais permitidas." e isso resulta no comentário do link 2:

• O pacote Zoom Debian Linux requer ibus. Mas o ibus faz parte da área de trabalho do GNOME. Portanto, instalar o zoom_amd64.deb no KDE Plasma quebra o suporte ao teclado devido ao ibus e dependências relacionadas que não funcionam no KDE.
• Sim, estou fazendo uma nova instalação do Zoom e de repente recebo dependências de ibus, libegl1-mesa, libxcb, python3-ibus, ibus-gtk e alguns outros. Estou usando uma distribuição Linux de alguns meses, portanto, NÃO deve haver motivo para o Zoom não ser instalado. Eu não preciso de ibus, isso vai arruinar minha configuração. Isso é uma loucura. . . Quando um gigante de bilhões de dólares como o Zoom contrata desenvolvedores abaixo da média para empacotar seu software, sem dúvida o trabalho mais importante em uma empresa de software - eles merecem falhar! Eu li os fóruns de suporte sobre este mesmo tópico e o fracasso absoluto da equipe de suporte em entender o peso desse problema foi inacreditável. Os mantenedores Debian do ibus fizeram postagens para tentar ajudar, mas a equipe do Zoom os ignorou. Considero isso uma falha enorme do Zoom e um tapa na cara dos usuários do Linux em todos os lugares.