Não é possível digitar caracteres não ingleses em determinados lugares

Question

Em determinados campos de texto, não consigo digitar caracteres não ingleses (digito um caractere, nada acontece). Exemplos são:

• Campo de pesquisa do traço Unity
• Barra de endereços do Chromium
• Caixa de mensagens Pidgin
• Caixa de mensagens do Gajim

Em outros lugares (como Terminal, barra de endereços do Firefox, campos de entrada em sites, etc.), a entrada desses caracteres funciona.

Editar:

$ locale
LANG=sr_RS.utf8@latin
LANGUAGE=sr_RS@latin:sr_RS:sr:en_US:en
LC_CTYPE="sr_RS.utf8@latin"
LC_NUMERIC=sr_RS
LC_TIME=sr_RS
LC_COLLATE="sr_RS.utf8@latin"
LC_MONETARY=sr_RS
LC_MESSAGES=sr_RS.UTF-8
LC_PAPER=sr_RS
LC_NAME=sr_RS
LC_ADDRESS=sr_RS
LC_TELEPHONE=sr_RS
LC_MEASUREMENT=sr_RS
LC_IDENTIFICATION=sr_RS
LC_ALL=

$ gsettings list-recursively org.gnome.desktop.input-sources
org.gnome.desktop.input-sources current uint32 0
org.gnome.desktop.input-sources per-window false
org.gnome.desktop.input-sources show-all-sources false
org.gnome.desktop.input-sources sources [('xkb', 'us'), ('xkb', 'rs+latin'), ('xkb', 'rs')]
org.gnome.desktop.input-sources xkb-options @as []

$ setxkbmap -query -v
Trying to build keymap using the following components:
keycodes:   evdev+aliases(qwerty)
types:      complete
compat:     complete
symbols:    pc+us+inet(evdev)
geometry:   pc(pc105)
rules:      evdev
model:      pc105
layout:     us

E quando mudo para um dos meus layouts fora dos EUA, recebo:

$ setxkbmap -query -v
Trying to build keymap using the following components:
keycodes:   evdev+aliases(qwerty)
types:      complete
compat:     complete
symbols:    pc+rs(latin)+us:2+inet(evdev)
geometry:   pc(pc105)
rules:      evdev
model:      pc105
layout:     rs,us
variant:    latin,

env:

$ env | grep -i im
CLUTTER_IM_MODULE=xim
XMODIFIERS=@im=ibus
EDITOR=/usr/bin/vim
IM_CONFIG_PHASE=1
QT4_IM_MODULE=xim
TEXTDOMAIN=im-config
XDG_RUNTIME_DIR=/run/user/1000
GTK_IM_MODULE=xim
LC_TIME=sr_RS

    

Answer 1

Confirmei que tive o mesmo problema no Unity e no Chromium com a mesma configuração que você está mostrando, mas corrigi-lo com a seguinte solução alternativa.

O problema existente é que, mesmo quando a barra de menu mostra corretamente que você alterou o layout para, digamos, S1 , o Unity reage como se estivesse usando o layout em inglês.

Ou seja, somente a saída em inglês é produzida, embora o indicador diga S1 . Pressionamentos de teclas no Unity produzirão apenas a chave inglesa, ou nada aparecerá se nenhuma tecla corresponder ao combo sérvio, ou outra parte da interface será disparada se o combo acionar o trigger. Outros aplicativos, no entanto, por exemplo, gedit , usarão corretamente o layout sérvio mostrado na barra de menus; mas o Unity ainda reage como se o layout estivesse configurado para inglês. Além disso, isso não é afetado pela alteração da fonte.

Existem 2 problemas:

1. Existe um bug em algum lugar.
2. Essa resposta fornece uma solução alternativa para o bug.

Por favor, note também que:

1. Isso não tem nada a ver com métodos de entrada. Isso funcionou com o método de entrada padrão definido como ibus , fcitx ou none .

2. Isso também não está relacionado a configurações em xkb-options , como Compose Key ou 3rd level chooser (referido como Alternative Characters Key em Teclado > > Digitação .

   (Você não tem nenhum desses conjuntos; esse ponto é apenas para ser completo.)

A configuração da chave é encontrada em Configurações do sistema > > TextEntry .

A configuração padrão é Use the same source for all windows . Infelizmente, a configuração padrão parece sempre criar o problema.

A solução alternativa é mudar isso para Allow different sources for each window .

A configuração New windows funcionará com qualquer uma das opções, mas use the default choice parece ser menos peculiar e funcionar corretamente de forma mais consistente.

Você não precisa sair e entrar, mas não faz mal. Neste ponto, a entrada com os teclados sérvios funciona na pesquisa do Chromium e do Unity. Bem, na maior parte do tempo. Descobri que o Unity ainda é às vezes um pouco peculiar, mas isso também é facilmente trabalhado.

Com New windows use the default source , as coisas funcionaram como esperado quase todo o tempo:

Ou seja, você abre o Unity, a fonte muda para o inglês, então você usa Ctrl + Espaço para mudar a fonte. Agora a fonte é S1 (latin) . A digitação [ produz corretamente š e as chaves que dependem de uma combinação também funcionam corretamente no Unity. Por exemplo, Right-Alt + a produz æ .

A peculiaridade é que às vezes a origem de entrada do Unity e a fonte de entrada exibida no indicador do teclado parecem estar fora de sincronia e você obtém ou continua a obter o problema conforme descrito acima.

O trabalho em torno dessa peculiaridade é percorrer as fontes de entrada. Pressione Ctrl + Espaço até você voltar para a fonte que deseja.

Isso sincroniza novamente as fontes de entrada mais do tempo. Algumas vezes eu tive que pedalar duas vezes. Outra vez, tive que percorrer as fontes, sair do Unity e reiniciar o Unity.

A boa notícia é que, quando as fontes são sincronizadas, elas parecem permanecer corretas durante o restante da sessão.

Melhor ainda, como mencionado acima, usar a configuração new windows use default source parece evitar que a peculiaridade aconteça em primeiro lugar quase o tempo todo.

A frequência dessa peculiaridade parece ser:

1. Abaixo da configuração padrão Use the same source for all windows : Always. Isso nunca vai funcionar.
2. Abaixo da configuração Allow different sources -- new use current source : Frequente. Andar de bicicleta através das fontes de entrada e, por vezes, sair / reiniciar o Unity é frequentemente necessário.
3. Abaixo da configuração Allow different sources -- new use default source : Raro. Funciona como pretendido na maior parte do tempo. Andar de bicicleta pelas fontes de entrada e, às vezes, sair / reiniciar o Unity necessário de vez em quando, mas não com frequência.

Eu não consegui encontrar esse bug no Launchpad, então você pode querer reportar um novo bug contra a troca de fonte de entrada. (Eu não tenho certeza do pacote exato para relatar.) Existem erros semelhantes no Launchpad, mas todos os que eu vi eram mais antigos e não estavam ativos.

    

Answer 2

Eu sugeriria que o problema é que, em alguns lugares, as fontes que você usa não têm os caracteres não latinos necessários. Tente verificar a área de trabalho inteira e, nos aplicativos que você usa, as fontes usadas têm uma grande variedade de caracteres cobertos, como a família de fontes Liberation ou DejaVu .